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Abstract 

Intelligence,  surveillance  and  reconnaissance  (ISR)  is  a  high-demand  Department 
of  Defense  mission  performed  by  unmanned  aircraft  systems  (UASs)  at  the  tactical  and 
theater  levels.  Coordinating  UASs  through  cooperative  control  offers  the  advantages  of 
persistence,  distributed  and  adaptable  sensor  coverage,  and  reduced  revisit  time  on  points 
of  interest.  The  purpose  of  this  thesis  is  to  apply  systems  engineering  principles  to  the 
problem  of  developing  a  flexible,  common  control  system  for  cooperative  UAS 
surveillance  at  the  tactical  level.  The  AFIT  team  developed  a  concept  of  operations 
(CONOPS)  encompassing  various  users  and  surveillance  tasks.  The  team  then  used  the 
scenarios  in  the  CONOPS  to  build  a  conceptual  architecture.  Concurrently,  the  team 
constructed  a  developmental  test  system  that  closely  resembled  the  architecture  and 
successfully  conducted  flight  tests  of  multiple  aircraft.  The  team  then  used  this 
architecture  and  the  prototype  system  to  identify  significant  technical  risks  and  future 
research  areas  to  be  explored  prior  to  the  development  of  an  operational  system. 
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COOPERATIVE  UNMANNED  AERIAL  SURVEILLANCE  CONTROL  SYSTEM 


ARCHITECTURE 


I.  Introduction 


Thesis  Introduction 

Current  experience  in  Iraq  and  Afghanistan  has  shown  an  ever-increasing  need  for 
the  use  of  unmanned  aircraft  systems  (UASs)  to  accomplish  a  variety  of  missions  within 
a  war-time  environment.  As  combat  theater  requirements  and  experience  with  UASs 
grow  from  the  widespread  success  of  these  platforms,  the  Department  of  Defense  (DoD) 
is  increasingly  relying  on  UASs  to  reduce  risks  to  humans  and  accomplish  a  multitude  of 
missions  that  were  previously  conducted  by  manned  systems.  These  missions  include 
performing  traditional  intelligence,  surveillance,  and  reconnaissance  (ISR)  activities,  in 
addition  to  conducting  search  and  rescue  (SAR)  and  broad  area  search  operations.  To 
date,  most  unmanned  aerial  vehicles  (UAVs)  operate  independently  and  physically 
separated  from  one  another  to  accomplish  a  specific  task  or  single  mission  objective. 

This  limits  the  amount  of  terrain  coverage  and  the  mission  flexibility  for  the  end  user.  To 
provide  additional  and  more  responsive  mission  capabilities  to  the  warfighter,  UAVs 
must  be  able  to  work  in  cooperative  formations  and  must  be  made  more  adaptable  to  a 
variety  of  mission  tasks  required  by  users  in  an  operational  theater.  To  implement 
cooperative  UAV  capabilities,  an  effective  architecture  that  enables  cooperative 
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command  and  control  of  existing  and  future  UAS  platforms  and  their  sensors  is 
necessary. 

To  explore  the  feasibility  and  effectiveness  of  real-world  cooperative  UAV 
operations,  this  team  developed  a  conceptual  system  architecture  for  a  cooperative  UAS 
designed  to  conduct  a  variety  of  ISR  missions.  Simultaneously,  the  team  constructed  a 
developmental  flight  test  system  using  “off-the-shelf’  components.  The  team  used  the 
architecture  and  prototype  system  to  investigate  a  number  of  risks  and  technology 
shortfalls  in  areas  such  as  UAV  and  sensor  control,  data  display,  and  communication 
bandwidth  in  the  operational  environment.  This  thesis  work  was  conducted  in 
conjunction  with  six  other  students,  exploring  specific  aspects  of  cooperative  control  and 
ISR  optimization:  collision  avoidance  (COLA),  efficient  flight  path  planning,  linear 
distributed  coverage  optimization,  sensor  aim  point  navigation,  and  trust  in  automation. 

Problem  Statement 

Current  UASs  must  operate  in  a  variety  of  conditions,  including  desert,  urban, 
maritime,  and  temperate  environments,  and  perform  numerous  diverse  and  challenging 
missions.  UAS  missions  may  require  operations  beyond  line-of-sight  of  the  tactical 
operator,  the  prosecution  of  time  sensitive  targets,  long  loiter  times,  and  the  ability  to 
carry  and  utilize  a  variety  of  sensors. 

While  the  DoD  is  the  predominant  federal  government  UAS  user,  numerous  other 
governmental  organizations,  such  as  the  Department  of  Homeland  Security  (DHS),  the 
U.S.  Coast  Guard,  and  the  Federal  Emergency  Management  Agency  (FEMA),  are 
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investigating  UASs  in  a  variety  of  remote  sensing  missions  such  as  law  enforcement, 
damage  assessment,  and  terrain  mapping  [1:3].  Each  agency  is  moving  quickly  to 
expand  or  create  its  own  UAV  fleet  with  little  or  no  regard  to  commonality  and 
interoperability.  Typically,  each  UAV  functions  as  a  single  vehicle  platform  conducting 
a  single  mission.  Each  UAS  also  creates  a  logistical  footprint,  including  numerous 
operators  and  support  personnel,  adding  a  significant  human  resource  requirement 
wherever  the  UAS  operates.  As  the  type,  complexity,  and  overall  number  of  UAS 
missions  increase,  operators  must  have  systems  for  mission  planning,  vehicle/sensor 
management  and  control,  displaying  and  recording  sensor  data,  and  producing 
surveillance  products  that  are  exportable  to  the  intelligence  consumer.  While  UAS 
design  is  expected  to  provide  increased  capabilities  to  future  warfighters,  it  must  also 
address  operator  burden  and  logistical  footprint  size. 

Scope  and  Assumptions 

The  AFIT  team  sought  to  develop  a  high-level  conceptual  architecture  for  a 
system  to  cooperatively  control  multiple  UAVs  in  a  variety  of  surveillance  missions. 
Additionally,  the  team  aimed  to  construct  and  test  a  prototype  system  for  researching 
cooperative  control  algorithms  and  to  thoroughly  document  test  plans  and  procedures  for 
future  groups.  The  team  documented  gaps  between  the  “as  built”  test  bed  and  the 
conceptual  architecture  through  a  test  architecture.  In  addition,  the  team  sought  to 
identify  risk  areas  and  provide  viable  mitigation  options  for  operational  system 
development  efforts.  The  team  also  provided  systems  engineering  support  in  integrating 
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and  testing  algorithms  developed  by  the  other  AFIT  students  conducting  cooperative 
control  studies. 

Based  on  previous  research,  the  team  began  with  the  assumption  that  a  Joint 
Capabilities  Integration  and  Development  System  (JCIDS)  analysis  had  been  performed, 
identifying  the  need  for  additional  ISR  capabilities  and  recommending  cooperative  UASs 
to  fulfill  those  needs.  The  team  focused  on  a  common  control  system  architecture 
designed  to  be  flexible  and  expandable  from  single  to  multiple  vehicles  ranging  in  size 
from  man-portable  micro  air  vehicles  (MAVs)  to  larger  systems  deployable  from  more 
traditional  airfields. 

Hardware  and  software  resource  constraints  limited  the  components  used  in  the 
test  system  and  how  closely  it  implemented  the  conceptual  architecture.  The  team 
restricted  the  testing  to  a  maximum  of  four  UAVs  of  the  same  type.  The  team  also 
limited  the  scope  of  the  tests  to  validating  the  ability  to  simultaneously  control  multiple 
UAVs,  gather  telemetry  and  sensor  data  from  multiple  UAVs,  and  utilize  student- 
developed  control  algorithms  to  perform  various  tasks  associated  with  the  mission  area. 

Thesis  Purpose 

The  purpose  of  this  thesis  is  to  develop  an  effective  and  expandable  architecture 
for  multi-UAV  cooperative  command  and  control.  To  support  this  effort,  the  team 
created  a  prototype  system  to  validate  the  theoretical  design,  identify  areas  of  technical 
risk,  and  support  the  development  of  cooperative  control  algorithms.  The  prototype 
system  can  serve  as  a  test  bed  for  future  cooperative  control  research.  The  team  also 
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identified  areas  where  additional  research  is  warranted  to  fully  understand  the 
requirements  and  limitations  of  cooperative  control  technologies. 

Thesis  Outline 

The  remainder  of  this  document  explores  several  of  the  challenges,  opportunities, 
results,  and  areas  of  future  research  that  will  be  required  to  produce  true  cooperative 
control  UAS  capabilities  for  tomorrow’s  warfighters.  Chapter  II,  Background,  examines 
capability  gaps  in  ISR,  provides  a  brief  history  of  UASs,  presents  an  overview  of 
cooperative  UAV  control,  and  examines  past  research  efforts.  Chapter  III,  Methodology, 
provides  a  brief  synopsis  of  the  systems  engineering  process,  an  account  of  how  this 
effort  was  scoped,  an  explanation  of  architectural  products,  and  a  description  of  the  test 
system  development  and  flight  testing.  Chapter  IV,  Results,  presents  the  conceptual 
cooperative  control  architecture  and  the  developmental  flight  test  system,  and  compares 
and  contrasts  differences  between  the  two.  It  examines  several  of  the  challenges  and 
limitations  associated  with  cooperative  control  systems  captured  by  in-flight  testing  and 
laboratory  simulation.  Additionally,  it  discusses  risk  issues  identified  during  architecture 
development,  lab  testing,  and  flight  testing.  Lastly,  Chapter  V,  Conclusions  and 
Recommendations,  summarizes  the  results  and  proposes  areas  of  research  for  additional 
study  to  create  effective  cooperative  UAS  capabilities. 
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II.  Background 


Intelligence,  Surveillance,  and  Reconnaissance 

The  collection  of  intelligence  information  plays  a  major  role  in  DoD  operations. 

It  helps  military  personnel  at  all  levels  understand  the  situations  they  face  and  make 
better  decisions.  Joint  doctrine  describes  the  goal  of  this  mission  by  stating,  "This  joint 
intelligence  effort  facilitates  that  degree  of  dominance  in  the  information  domain  which 
permits  the  conduct  of  operations  without  effective  opposition"  [2:xi],  Its  importance  is 
evidenced  by  its  inclusion  at  high  levels  of  joint  and  service  doctrine.  The  mission  of 
collecting,  analyzing,  and  disseminating  battlespace  information  is  often  referred  to  as 
Intelligence,  Surveillance,  and  Reconnaissance  (ISR).  The  DoD  terminology  dictionary 
defines  ISR  as: 

An  activity  that  synchronizes  and  integrates  the  planning  and  operation  of 
sensors,  assets,  and  processing,  exploitation,  and  dissemination  systems  in 
direct  support  of  current  and  future  operations.  This  is  an  integrated 
intelligence  and  operations  function.  [3:273] 

Although  ISR  is  often  used  to  describe  a  single  type  of  mission,  the  acronym's 
individual  terms  have  different  meanings.  Reconnaissance  refers  to  collecting  specific 
information  on  an  area  or  point  of  interest,  generally  for  an  instant  or  short  period  of  time. 
Surveillance  aims  to  maintain  sustained  observation  of  an  area  of  interest  over  a  specified 
period  of  time  (generally  longer  than  reconnaissance).  Intelligence  is  the  knowledge  and 
information  gained  from  operations  like  surveillance  and  reconnaissance  [4:2], 

This  thesis  most  often  uses  the  term  "surveillance"  when  referencing  the  system 
explored  in  this  research,  because  a  persistent  observation  capability  was  the  driving 
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factor  in  its  design.  It  should  be  noted,  however,  that  the  capabilities  of  the  system  also 
encompass  performing  reconnaissance  and  producing  intelligence.  "Surveillance"  is  used 
for  consistency,  but  the  reader  should  understand  this  is  inclusive  of  other  ISR  activities. 

Unmanned  Aircraft  Systems 
Overview  and  History. 

Intelligence  collection  is  performed  by  humans  as  well  as  mechanical  systems. 
Technological  collection  methods  include  an  array  of  vehicles  and  sensors  including 
ground  listening  stations,  satellites,  and  manned  and  unmanned  aircraft.  Unmanned 
systems,  particularly  aerial  ones,  are  playing  a  growing  role  in  the  ISR  mission.  UASs 
are  composed  of  UAVs,  the  ground  operators  that  control  them,  and  the  associated 
hardware  that  facilitates  command,  control,  and  communication  between  the  operators 
and  vehicles. 

The  UAS  concept  has  been  used  for  a  surprisingly  long  time.  During  the  U.S. 
Civil  War,  both  sides  launched  balloons  loaded  with  explosives  at  each  other  [5].  The 
technology  to  remotely  pilot  aircraft  was  developed  after  World  War  II,  facilitating  the 
predecessors  of  today’s  modem  UASs.  In  the  Vietnam  conflict,  the  AQM-34  Firebee 
drone,  shown  in  Figure  1,  conducted  a  wide  variety  of  missions  including  camera 
surveillance,  leaflet  dropping,  and  surface-to-air  missile  detection  [5].  During  the  1980s, 
extensive  Israeli  research  led  directly  to  U.S.  systems  like  the  Hunter  and  Pioneer  UAVs, 
also  shown  in  Figure  1.  The  latter  was  used  in  Operation  Desert  Storm  to  spot  shelling 
locations  for  U.S.  warships  [5]. 
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Recent  advances  have  produced  larger  and  longer  endurance  UASs,  including 
the  RQ-4  Global  Hawk  UAV  which  has  a  1 16  foot  wingspan  [6]  and  can  loiter  for  over 
24  hours  [5],  UAS  communication  technology  has  also  advanced  enough  to  enable  the 
Predator  and  Global  Hawk  UAVs,  shown  in  Figure  1,  to  be  routinely  controlled  from 
ground  stations  on  the  opposite  side  of  the  world. 


RQ-5  Hunter 


AQM-34Firebee 


RQ-2  Pioneer 


MQ-1  Predator 


RQ-4  Global  Hawk 


V$  J-H  fcstc 


Figure  1.  UAV  Photographs  [7;  8;  9;  10;  11] 


The  development  of  UASs  has  been  spurred  primarily  by  a  desire  to  reduce  the 
risk  to  human  life  by  removing  the  operator  from  exposure  to  threats.  This  includes 
enemy  fire,  but  also  harsh  environmental  conditions  such  as  the  presence  of  radiation  or 
chemical  agents.  Unmanned  systems  offer  a  number  of  other  advantages  as  well. 
Because  the  operators  can  be  swapped  out  without  the  aircraft  landing,  UAV  mission 
lengths  are  not  limited  by  human  endurance  factors.  Also,  without  the  need  to 
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accommodate  a  pilot  and  the  associated  life-support  systems,  UAVs  can  be  built  smaller, 
lighter,  and  more  agile  than  manned  aircraft.  This  makes  them  generally  harder  to  detect 
as  they  execute  their  assigned  mission.  The  lack  of  onboard  human  support  systems  also 
lowers  the  overall  cost  of  the  UAV  compared  to  a  similar  piloted  aircraft.  However, 
there  are  added  costs  and  complexities  associated  with  the  ground  control  hardware  and 
communications  equipment  of  unmanned  systems. 

Categories. 

Several  methods  of  categorization  have  been  used  to  describe  UASs.  The 
Unmanned  Systems  Roadmap  (2007-2032)  was  created  to  provide  a  common  vision  for 
the  development  of  unmanned  systems.  It  separates  UASs  into  three  size  categories: 
Small  -  less  than  55  pounds;  Tactical  -  55  to  1320  pounds;  and  Theater  -  over  1320 
pounds  [12:20],  It  also  distinguishes  a  Combat  category  as  a  weapons-carrying  strike 
platform  weighing  over  1320  pounds  [12:20],  Other  sources,  like  the  Government 
Accountability  Office  (GAO),  make  a  very  similar  delineation.  The  GAO  classifies 
UASs  into  three  categories  based  on  size  and  mission:  Man-Portable  -  small,  self- 
contained,  and  controlled  at  the  combat  team  level;  Tactical  -  larger,  supporting  various 
levels  of  tactical  command;  and  Theater  -  controlled  by  theater  commanders  and 
supporting  theater-level  requirements  [13:8], 

In  an  article  in  Joint  Force  Quarterly,  Lieutenant  General  David  Deptula  suggests 
that  referring  to  UASs  by  their  level  of  war,  i.e.,  "tactical,"  "operational,"  or  "strategic,"  is 
flawed  since  any  system  can  be  employed  at  any  level.  He  recommends  classifying  them 
in  terms  of  their  overall  capabilities,  e.g.,  aircraft  performance,  sensors,  ground  support, 
etc.,  and  divides  them  into  two  categories:  Local-Area  and  Theater-Level  [14:49-50], 
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The  system  discussed  in  this  thesis  is  designed  to  be  operated  by  and  provide 
surveillance  for  units  deployed  on  the  battlefield.  Its  capabilities  can  support  foot 
soldiers,  convoy  commanders,  or  other  tactical  users,  and  are  not  dependent  on  the  size  of 
the  UAV  platform.  While  the  team  often  refers  to  the  system  as  "tactical,"  this  term  is 
most  closely  related  to  the  "Local- Area"  category  described  by  LtGen  Deptula,  rather 
than  being  descriptive  of  any  size  or  weight  constraints. 

Growing  Requirements. 

The  use  of  UASs  has  grown  dramatically  over  the  last  decade.  In  an  article  for 
Joint  Force  Quarterly,  Colonel  Jeffrey  Kappenman  notes  that  the  number  of  UAV 
airframes  in  the  DoD  inventory  increased  from  less  than  50  in  2000  to  over  3,900  in  2007 
[13:2],  As  of  April  2008,  Army  UAVs  alone  had  flown  over  375,000  hours  and  almost 
130,000  sorties  in  Iraq  and  Afghanistan  [15:21],  As  the  experience  and  successes  with 
UASs  has  continued  to  grow,  the  number  and  types  of  missions  these  systems  are  tasked 
to  execute  has  expanded.  Current  operations  in  Iraq  and  Afghanistan  routinely  involve 
UAVs  that  carry  and  employ  munitions.  Additional  missions  being  explored  include 
search  and  rescue,  broad  area  search,  and  logistical  supply  delivery.  To  support  this 
growth,  the  2006  Quadrennial  Defense  Review  (QDR)  specifically  states  plans  to  further 
increase  the  development  and  procurement  of  UASs  [16:6,57], 

The  increased  demand  for  UASs  has  been  due,  at  least  partially,  to  a  capability 
gap  in  meeting  ISR  mission  needs.  The  2006  QDR  cites  the  need  for  UASs  to  "increase 
persistent  surveillance,  nearly  doubling  today's  capacity,"  and  to  "provide  more  flexible 
capabilities  to  identify  and  track  moving  targets  in  denied  areas"  [16:6,57],  In  a  survey  of 
combatant  command  (COCOM)  and  military  department  unmanned  vehicle  needs, 
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"Reconnaissance"  was  listed  as  the  number  one  priority  over  all  three  domains:  land,  sea, 
and  air  [12:21-23],  "Precision  Target  Location  and  Designation,"  a  related  ISR  task,  was 
listed  as  the  number  two  priority  for  UASs  [12:21],  According  to  Col  Kappenman, 

"Army  commanders  at  all  tactical  levels  (division  and  below)  have  identified  a 
requirement  for  organic  UAS[s]  to  support  their  operations"  [15:20], 

As  more  UASs  are  assigned  to  performing  ISR  tasks,  corresponding  tactics, 
techniques,  and  procedures  have  been  developed  to  employ  them  for  surveying  ground 
routes,  base  perimeters,  large  areas,  and  particular  features  of  interest  [17],  There  are 
tactical  convoy  operations  procedures  for  using  UASs  to  scout  roads  and  escort  vehicles 
as  they  traverse  Main  Supply  Routes  (MSRs)  in  wartime  theaters  [18],  Although  UASs 
are  predominantly  associated  with  military  intelligence  collection,  their  use  is  not  limited 
to  the  DoD.  U.S.  Customs  and  Border  Protection  are  flying  Predator  B  aircraft  to  search 
for  smugglers  and  illegal  immigrants,  while  the  U.S.  Forest  Service  is  also  using  them  to 
locate  and  map  forest  fires  [19], 

Cooperative  Control 
Definition. 

Cooperative  control  is  one  of  the  newest  concepts  being  explored  for  UASs.  It 
refers  to  the  coordinated  direction  of  UAV  platforms  in  order  to  create  synergy  in  their 
operations.  This  coordinated  control  produces  cooperative  behavior  among  UAVs.  It  not 
only  affects  the  UAVs'  flight  paths,  but  their  sensor  aim  points  and  settings  as  well. 
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The  2007  Unmanned  Systems  Roadmap  lists  Cooperative  Behavior  as  one  of  its 
technology  development  objectives  [12:50],  It  distinguishes  collaboration  between 
unmanned  systems  from  collaboration  between  unmanned  and  human  systems  [12:50- 
51].  Although  it  addresses  aspects  of  the  latter,  this  research  is  primarily  concerned  with 
the  former:  unmanned  platforms  acting  in  concert  with  one  another  as  a  team  or  in  a 
formation. 

Persistent  Surveillance. 

Cooperative  control  offers  several  capability  improvements  in  conducting  ISR 
tasks.  First,  it  allows  a  greater  degree  of  persistence  in  surveillance.  On-station  aircraft 
can  be  replaced  when  they  run  low  on  fuel  or  encounter  malfunctions.  A  continuous 
cycling  of  fresh  UAVs  provides  the  possibility  of  indefinite  surveillance  of  an  objective. 
In  some  cases,  a  single  UAV  cannot  physically  keep  its  sensor  coverage  on  a  target 
because  of  its  flight  path  through  the  environment.  For  example,  if  the  door  on  one  side 
of  a  tall  building  is  the  objective,  the  single  UAV's  sensor  may  not  be  able  to  maintain 
visibility  on  the  door  because  of  masking  by  the  airframe  or  building  as  the  UAV  turns. 
By  cooperatively  positioning  two  or  more  UAVs,  sensor  coverage  of  the  door  can  be 
provided  by  one  aircraft  when  it  is  obscured  from  another. 

Increased  Sensor  Coverage. 

Using  a  greater  number  of  UAVs  and  sensors  in  the  air  at  the  same  time  increases 
the  effective  sensor  footprint  of  the  entire  system  and  allows  individual  sensor  coverages 
to  be  dispersed  over  an  area.  Multiple  UAVs  can  search  a  defined  zone  more  quickly 
than  a  single  vehicle  by  breaking  up  the  task  into  smaller  pieces  for  each  to  cover.  The 
combined  coverage  may  also  be  concentrated  in  one  geographic  location.  For  example, 
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multiple  UAVs  flying  in  a  line-abreast  formation  can  effectively  provide  a  combined 
wide  field-of-view  out  in  front  of  them. 

Adaptable  Sensor  Coverage. 

Coordinating  multiple  UAVs  allows  the  overall  effect  of  their  combined  sensor 
coverage  to  be  reconfigured.  This  change  can  be  in  response  to  the  behavior  of  the 
surveillance  subject.  If  the  system  is  tracking  a  vehicle,  all  sensors  may  be  centrally 
fixed  on  that  target;  however,  if  the  vehicle  enters  a  covered  parking  garage,  the  sensors 
may  be  distributed  to  cover  all  the  exits  from  the  garage.  This  reconfiguration  can  also 
support  a  change  in  the  focus  of  the  mission.  For  example,  four  UAVs  may  be  surveying 
a  large  area  when  one  locates  a  target  of  interest.  The  coverage  can  then  be  adapted  so 
that  one  or  two  UAVs  focus  sensors  on  the  target  while  the  others  continue  the  area 
surveillance. 

Reduced  Revisit  Time. 

When  surveilling  a  large  area,  perimeter,  or  route,  the  time  between  sensor  passes 
over  any  particular  point  (revisit  time)  is  a  key  mission  parameter.  A  longer  revisit  time 
increases  the  chance  that  a  fleeting  target  or  activity  of  interest  will  be  missed  by  the 
surveillance  system.  By  using  multiple  UAVs  and  coordinating  their  actions,  the  overall 
revisit  time  can  be  reduced,  and  the  system  can  be  optimized  to  meet  a  particular  desired 
revisit  time. 
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Recent  Research 


A  variety  of  research  has  begun  to  emerge  relating  to  UAS  architectures  and 
cooperative  control.  The  team  surveyed  a  number  of  sources  to  establish  a  baseline  for 
the  present  work. 

Scholarly  Research. 

Many  recent  scholarly  papers  have  addressed  aspects  of  cooperative  UAS  control. 
Their  topics  range  from  task  allocation  optimization  [20],  to  resource  allocation  [21],  to 
path  planning  optimization  [21],  and  collision  avoidance  [22],  Other  efforts  have 
developed  functional  hardware-in-the-loop  ground  test  systems  [23]  and  multi-UAV 
flight  test  systems  [24;  25]  to  evaluate  control  schemes.  These  research  groups 
documented  aspects  of  their  system  architectures,  such  as  communications  and  vehicle 
internal  data  flows  [24:2];  however,  none  attempted  to  apply  a  comprehensive  systems 
engineering  approach  to  developing  a  cooperative  control  system  and  corresponding 
architecture. 

AFRL. 

The  Air  Force  Research  Laboratory  (AFRL)  at  Wright  Patterson  Air  Force  Base 
(AFB),  OH  is  dedicated  to  investigating  new  technologies  to  aid  the  warfighter.  It  is 
currently  conducting  studies  on  fielding  cooperative  UASs  for  a  variety  of  ISR  tasks, 
including  route,  perimeter,  and  urban  surveillance.  The  team  consulted  with  several 
members  of  AFRL  throughout  the  course  of  the  project  to  stay  abreast  of  ongoing 
research  efforts. 
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AFRL  identified  a  number  of  areas  for  closer  study  to  include: 

-  Communications  constraints  in  pushing  high  bandwidth  data  (such  as 
video  streams)  over  long  distances  using  size-constrained  vehicles. 

-  Relay  communications  technologies  to  pass  commands  and  data  between 
UAVs  in  a  formation. 

-  Optimization  of  UAV  coverage  across  a  linear  path  to  minimize  revisit 
time. 

-  Adaptation  to  UAV  formation  changes  such  as  aircraft  insertion, 
deletion,  and  reordering. 

-  Methods  for  dealing  with  system  disturbances  such  as  wind. 

-  Collision  avoidance  methods. 

AFRL  researcher  Dr.  Derek  Kingston  co-authored  a  paper  that  explored  a 
decentralized  approach  to  cooperative  perimeter  surveillance.  His  research  group 
reduced  the  data  passed  to  each  UAV  down  to  the  perimeter  length,  and  the  number  of 
vehicles  on  either  side  of  each  UAV.  Additionally,  each  aircraft  passed  data  to  any 
aircraft  it  met  in  flight,  effectively  extending  the  communication  range  of  the  system. 

The  algorithm  accounted  for  a  changing  perimeter  size  as  well  as  the  insertion  or  deletion 
of  UAVs  from  the  team.  His  group  demonstrated  the  ability  to  perform  a  coordinated 
distribution  of  UAVs  with  limited  communications  range  and  bandwidth  [26], 

AFIT  Theses. 

The  research  in  this  paper  directly  follows  from  several  previous  AFIT  projects. 

In  2004-2005,  Captain  Cory  Cooper,  Matthew  Ewoldt,  Steaven  Meyer,  and  Edward 
Talley  developed  operational  scenarios  and  a  systems  architecture  for  an  unmanned 
MAV  ISR  system  [27],  They  directly  identified  Special  Operations  Command  (SOCOM) 
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counter-terrorism  and  special  reconnaissance  ISR  requirements,  and  traced  how  their 
envisioned  system  met  identified  needs  [21]. 

Major  Laird  Abbot,  Christian  Stillings,  Maj  Craig  Phillips,  and  Capt  Garrett 
Knowlan  conducted  a  systems  engineering  analysis  in  conjunction  with  an  AFRL 
program  to  develop  a  UAS  for  finding,  tracking,  and  engaging  high-value  fleeting  targets 
in  2006-2007.  They  produced  a  mission  area  analysis,  architecture  products,  and  risk 
mitigation  and  test  planning  recommendations  to  support  the  acquisition  of  a  functional 
system  [28],  One  of  their  primary  conclusions  was  that  a  rigorous  systems  engineering 
process  is  beneficial  and  necessary  when  designing  systems  to  meet  warfighter 
requirements,  even  when  those  needs  are  urgent  and  a  rapid  acquisitions  process  is  used 
[28:129,  131]. 

Lieutenant  Commander  Gregory  Sakyrd  and  Capt  Douglas  Ericson  continued 
these  efforts  in  2007-2008.  They  developed  a  working  Fleeting  Target  Technology 
Demonstrator  to  serve  as  a  test-bed  for  MAV  research  [29],  Their  setup  included  a 
commercial  off-the-shelf  (COTS)  autopilot  and  control  software  installed  on  a  gas- 
powered  remote  controlled  (RC)  aircraft  [29:28-32],  LCDR  Sakyrd  and  Capt  Ericson's 
main  emphasis  was  developing  a  mission-focused  software  interface  that  operated  in 
conjunction  with  the  COTS  control  software.  Their  Fleeting  Target  Controller  interface 
was  designed  to  incorporate  tools  to  predict  an  intercept  path  to  a  fleeting  target  and  to 
allow  the  operator  to  guide  the  MAV  on  a  terminal  trajectory  [29], 

In  conjunction  with  LCDR  Sakyrd  and  Capt  Ericson's  research,  Capt  Nate 
Teming  developed  an  algorithm  to  heuristically  determine  the  optimal  flight  path  to  place 
a  UAV  sensor  on  a  moving  target  [30],  His  Pathmaker  algorithm  was  incorporated  into 
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LCDR  Sakyrd  and  Capt  Ericson's  Fleeting  Target  Controller,  allowing  the  operator  to 
generate  a  flight  plan  from  specified  target  parameters  [30], 

Ensign  Troy  Vantrease  also  worked  with  LCDR  Sakyrd  and  Capt  Ericson.  He 
created  and  tested  a  Cursor-on-Target  interface  integrated  with  the  Fleeting  Target 
Controller  [31].  It  allowed  an  operator  to  provide  terminal  guidance  to  a  MAV  through 
mouse  commands  on  the  sensor  video  screen  [31]. 

Concurrent  with  the  Fleeting  Target  Controller  work,  Second  Lieutenant  John 
Hansen  researched  guidance  of  a  relay  MAV  for  passing  sensor  and  command  data 
between  an  ISR  MAV  and  its  base  station  [32],  In  addition  to  computational  results,  he 
tested  relay  communications  hardware  with  LCDR  Sakyrd  and  Capt  Ericson's  flight  test 
setup  [32], 

Concurrent  Research. 

As  with  LCDR  Sakyrd  and  Capt  Ericson's  efforts,  this  research  was  conducted  in 
conjunction  with  other  AFIT  students,  each  addressing  a  different  aspect  of  the 
cooperative  UAS  surveillance  problem.  The  team  shared  resources  and  knowledge  with 
the  other  students,  and  they,  in  turn,  contributed  to  the  team’s  understanding  of  the 
system  requirements. 

Capt  Shannon  Farrell  researched  UAV  flight  paths  to  keep  a  target  in  the  UAV's 
fixed  sensor  FOV  [33],  He  explored  efficient  orbits  to  keep  a  side-mounted  camera 
pointed  at  a  target,  as  well  as  flight  paths  to  achieve  desired  sensor-to-target  look  angles 
from  a  side  or  front-mounted  camera  [33],  Capt  Chris  Booth  developed  a  software 
algorithm  to  converge  multiple  UAVs  on  a  single  target  [34],  His  program  calculates 
efficient  flight  paths  for  one  to  four  UAVs  at  any  starting  location.  It  coordinates  their 
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arrival  into  an  orbit  around  the  target  and  maintains  them  at  equidistant  spacing  around 
the  target  once  in  orbit  [34],  Capt  Joe  Rosal  explored  the  optimization  of  UAV 
surveillance  along  a  linear  path,  such  as  a  road  or  base  perimeter  [35],  Austin  Smith 
worked  on  the  problem  of  UAV  collision  avoidance.  He  created  a  centrally-monitored 
deconfliction  program  to  detect  potential  collisions  and  issue  proper  avoidance 
commands  in  the  form  of  pitch,  turn  rate,  and  airspeed  changes  [36],  Maj  Adam 
Lenfestey  and  Capt  Eric  Cring  examined  methods  for  building  trust  into  automated 
systems.  They  focused  on  control  of  multiple  UAVs  in  their  study  [37], 
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III.  Methodology 


Systems  Engineering 

Presented  with  a  basic  understanding  and  requirement  for  cooperative  UAS 
command  and  control  capability,  the  team  utilized  a  systems  engineering  approach  to 
ensure  the  complete  construction,  description,  and  capture  of  a  conceptual  architecture 
and  a  flight  test  system  that  was  used  to  explore  and  evaluate  the  concept  of  cooperative 
UAS  control.  The  architecture  is  hereafter  referred  to  as  the  Cooperative  Unmanned 
Surveillance  System  (CUSS). 

Systems  Engineering  Process. 

A  representative  systems  engineering  process  follows  the  format  in  Figure  2.  It 
begins  by  capturing  the  process  inputs  to  the  system,  including  mission  requirements, 
customer  requirements,  system  constraints,  and  a  description  of  the  environment  in  which 
the  system  must  operate.  These  requirements  are  then  analyzed  and  decomposed  into 
functional  requirements  to  ensure  a  complete  understanding  of  the  functions  the  system 
must  accomplish.  As  part  of  this  process,  performance  requirements  are  allocated  to  the 
lowest  level  of  functional  decomposition  necessary  to  ensure  requirements  traceability 
back  to  the  process  inputs.  As  functional  decomposition  and  allocation  of  system 
requirements  continue,  they  are  also  iterated  through  a  loop  with  requirements  analysis  to 
ensure  each  function  is  properly  tied  to  a  system  requirement.  Once  functional  analysis 
has  sufficiently  matured,  the  system  begins  to  take  on  physical  shape  as  the  architecture 
is  transformed  during  the  synthesis  stage  of  systems  engineering.  Functional  and 
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physical  trade-offs  continually  occur  during  the  design  loop;  however,  the  system  is  still 
compared  to  initial  requirements  to  ensure  it  meets  the  necessary  functionality.  This 
entire  process  is  iterated  using  a  system  analysis  and  control  step  until  the  design  team 
arrives  at  a  system  that  satisfactorily  meets  the  requirements,  goals,  and  constraints 
identified  as  process  inputs. 


Process  Input 

-  Customer  Needs-'Qbjectivesf 
Requirements 

-  Missions 

-  Measures  of  Effectiveness 

-  Environments 

-  Constraints 

-  Technology  Ease 

-  Output  Requirements  fmm  Prior 
Development  Effort 

-  Program  Decision  Requ  rements 

-  Requirements  Applied  Through 
Specifications  and  Standards 


Requirements  Analysis 

Analyze  Missions  and  Environments 
Identify  Functional  Requirements 
□ef  ne.'Refine  Performance  and  Design 
Constraint  Requirements 


Requirements  Loop 


F  un  ct  i  on  a  I  A  n  aiysis.1  Al  location 

Decompose  to  Lower-Level  Functions 

Allocate  Performance  and  Other  Limiting  Requirements 

to  All  Functional  Levels 

□ef  ne.'Refine  Functional  Interfaces  (krternalJEjctemal) 
□efine/Refine/Inlegrate  Functional  Architecture 


Design  Loop 

Synthesis 

Transfcmi  Architectures  {Functional  to  Physical} 
Define  Alternative  System  Concepts,  Configuration 
ItEms  and  System  Elements 
Select  Preferred  Product  and  Process  Solutions 
Defir efRef me  Physical  Interfaces  (triternaUEstemal) 


Related  Terms: 

Customer  =  Organizations  responsible  tor  Primary  Functions 
Primary  Functions  =  Development,  Production-Construction.  Verification. 

Deployment,  Operations,  Support,  Training,  Disposal 
Systems  Elements  =  Hare  ware,  Software,  Personnel.  Facilities.  Data,  Material, 
Services,  Techniques 


Process  Output 

■  Development  Level  Dependent 
—  Decision  Database 
—  System/Configuration  Item 
Architecture 

—  Specifications  and  Baselines 


Figure  2.  Systems  Engineering  Process  [38] 


DoDAF. 

In  addition  to  providing  a  development  framework,  a  systems  engineering 
approach  also  ensures  that  inherent  complexities,  such  as  those  introduced  by  cooperative 


control  schemes,  are  understood.  This  allows  the  team  to  maintain  the  technical  integrity 
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of  the  architecture  as  it  matures.  To  assist  in  this  effort,  the  team  used  a  subset  of  the 
Department  of  Defense  Architecture  Framework  (DoDAF)  to  create  and  document  the 
system’s  architecture  as  it  evolved.  The  use  of  architectures  in  the  development  of  DoD 
weapons  systems  is  required  by  law,  and  supported  by  JCIDS  [39]  and  the  Defense 
Acquisition  Guidebook  -  DoDD  5000.1  and  DoDI  5000.2  [40], 

The  DoDAF  is  an  integrated  set  of  products  and  views  where  each  term, 
definition,  and  relationship  across  the  architecture  is  uniquely  identified  and  consistently 
used.  This  process  enables  complex  systems  to  be  decomposed  into,  or  assembled  from, 
manageable  and  standardized  components  that  support  the  “clarification  of  roles, 
boundaries  and  interfaces”  between  each  product,  and  improves  common  understanding 
among  stakeholders  and  across  organizational  boundaries  [41:5]. 

JCIDS  Assumptions. 

To  initiate  the  systems  engineering  process,  the  CUSS  team  reviewed  on-going 
UAV  operations  as  well  as  the  extensive  work  provided  by  previous  research  efforts  and 
sponsored  AFIT  theses.  This  work  includes  the  significant  JCIDS  analysis  and  the 
corresponding  Functional  Area  Analysis,  Function  Needs  Analysis,  and  Functional 
Solution  Analysis  documentation  provided  by  Maj  Laird,  et  al.  [28],  It  clearly  identifies 
the  current  needs,  desired  capabilities,  and  functional  gaps  associated  with  singular  UAV 
operations  on  today’s  battlefields  for  several  specific  use  cases.  The  Fleeting  Targets 
research,  however,  was  narrow  in  scope  and  limited  to  a  single  operational  scenario. 
Based  on  the  capability  gaps  identified  by  Maj  Laird,  et  al.  and  the  Unmanned  Systems 
Roadmap,  the  team  assumed  that  a  cooperative  control  system  would  enhance  the  UAS 
solution  identified  in  the  Functional  Solution  Analysis.  The  team  also  assumed  that  an 
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expansion  of  the  scope  of  the  system  to  include  many  types  of  surveillance  tasks,  rather 
than  focusing  on  a  single  mission  thread,  would  close  more  capability  gaps  and  help 
achieve  the  Unmanned  Systems  Roadmap  stated  goal  of  increased  commonality  [12:4], 

Concept  of  Operations 

With  a  clear  statement  of  need  for  cooperative  command  and  control  of  UASs 
providing  the  basis  for  the  conceptual  system  definition,  the  team  then  focused  on 
understanding  what  the  system  must  do,  where  and  how  it  will  be  operated,  and  who  will 
operationally  control  and  receive  information  derived  from  the  system.  Identifying  these 
specific  mission  and  user  requirements  associated  with  the  concept  definition  was  the 
basis  of  the  Concept  of  Operations  (CONOPS).  This  analysis  and  brainstorming  included 
looking  at  current  DoD  employment  of  UASs,  in  addition  to  both  historical  and  proposed 
future  implementations  of  UAV  platforms  [42],  The  team  also  conducted  interviews  with 
current  UAS  operators,  Air  Force  Special  Operations  Command  personnel  with  expertise 
in  UAS  operations,  and  recently  deployed  personnel.  These  first-hand  accounts  enabled 
the  team  to  understand  unique  war-time  requirements  associated  with  UAS  operations 
and  capture  a  wide  array  of  current  and  potential  future  missions  for  cooperative  UASs. 

The  CUSS  CONOPS  describes  the  system's  overall  purpose,  time  horizon,  risks, 
military  challenges,  high  level  synopsis  of  system  execution,  desired  effects,  necessary 
and  enabling  capabilities,  and  sequenced  actions.  Development  of  this  CONOPS  also 
provided  insight  into  the  potential  implications  that  cooperative  UAS  command  and 
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control  may  have  in  the  areas  of  Doctrine,  Operations,  Training,  Materiel,  Leadership, 
Personnel,  and  Facilities  [42],  The  CONOPS  is  presented  and  discussed  in  Chapter  IV. 

Conceptual  Architecture 

System  Context. 

Once  the  CONOPS  was  established,  it  became  necessary  to  define  the  system 
context  in  which  the  UAS  would  be  operating.  Per  Dennis  Buede  in  The  Engineering 
Design  of  Systems,  the  CUSS  has  two  types  of  interactions  with  systems  outside  of  its 
own  boundary.  The  first  is  External  Systems  that  interact  and  exchange  information  with 
the  CUSS.  In  this  relationship,  both  the  CUSS  and  External  Systems  are  able  to  impact 
and  exchange  information  with  one  another,  such  as  passing  data  to  and  receiving 
information  from  a  node.  The  second  of  these  are  Context  Systems  which  also  exist 
outside  the  boundary  of  the  CUSS,  but  can  influence  and  send  information  to  the  CUSS 
and  other  External  Systems.  The  CUSS  is  unable  to  impact  or  send  information  to 
Context  Systems,  nor  change  their  state  or  behavior.  These  relationships  are  illustrated  in 
Figure  3  [43:124],  By  carefully  developing  the  CUSS  context  diagram,  the  team  created 
the  initial  scoping  and  limitations  of  the  cooperative  control  challenge  the  team  would 
address. 
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DoDAF  Product  Choices. 

Once  the  boundary  of  the  system  was  identified  through  the  context  diagram,  the 
team  used  the  DoDAF  to  create  the  necessary  architecture  products  required  to  describe 
the  conceptual  system.  There  are  four  major  sets  of  views  associated  with  the  DoDAF: 
the  Operational  Views  (OV),  the  System  Views  (SV),  and  the  Technical  Views  (TV) 
which  are  each  supported  by  the  All  Views  (AV).  The  All  Views  contain  high  level 
summary  and  overview  information  as  well  as  an  integrated  dictionary  that  provides  a 
glossary  of  each  term  used  within  the  architecture.  Among  these  views,  there  are  a  total 
of  29  interrelated  products  that  can  be  used  to  fully  document  and  describe  the  system 
under  design;  however,  only  a  subset  of  these  products  is  produced  in  most  development 
efforts.  A  suggested  process  flow  for  creating  each  DoDAF  product  is  found  in  Figure  4 

[41]. 
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DoD  Framework  Products 
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Figure  4.  Prescribed  DoDAF  Process  Flow  [44] 


Because  enormous  resources  may  be  required  to  produce  a  full  set  of  architecture 
products,  the  DoDAF  is  tailorable  based  on  program  requirements,  scope,  and  overall 
system  needs.  An  abbreviated  DoDAF  process  was  chosen  to  produce  conceptual  design 
products  consistent  with  the  system  definition  and  context  diagram.  These  products 
focused  team  efforts  on  capturing  the  essence  of  the  required  functionality  to  achieve 
cooperative  command  and  control  of  multiple  UAVs  simultaneously.  After  the  system 
CONOPS  was  finalized,  the  team  used  the  sequence  in  Figure  5  to  develop  the  required 
products  for  the  conceptual  CUSS  architecture. 
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Figure  5.  Architecture  Product  Sequence  Used  [44] 


Production  of  Architecture  Views. 

As  the  team  formulated  the  problem  statement  and  needs  associated  with 
cooperative  UAV  control,  this  information  became  the  AV-1,  a  high  level  overview  and 
summary  that  describes  the  CUSS  and  what  it  is  expected  to  accomplish  at  an  executive 
level.  As  the  architecture  evolved,  the  AV-2  was  created  to  define  each  term,  entity,  need 
line,  and  function  identified  within  the  architecture. 

Bounded  by  these  two  AV  documents,  the  team  began  development  of  the  CUSS 
OV  products  by  describing  the  operational  elements,  tasks  and  activities,  and  information 
flows  by  creating  an  OV-1  or  High-Level  Operational  Concept  Graphic.  This  view 
provides  a  quick,  readily  understandable  description  of  what  the  CUSS  is  supposed  to  do 
and  how  it  will  operate  [45],  It  depicts  the  CUSS  operational  concept  and  highlights 
several  of  the  main  operational  nodes  associated  with  the  architecture.  This  view  also 
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provides  insight  into  the  system  interactions  between  the  CUSS  and  its  environment  and 
its  interfaces  with  external  systems. 

The  second  OV  product  created  for  the  CUSS  was  the  Operational  Activity 
Diagram  or  OV-5.  This  view  displays  the  external  systems  that  interface  with  the  CUSS 
and  decomposes  the  operational  activities  and  capabilities  required  to  execute  the 
mission.  For  the  purposes  of  this  system,  the  OV-5  was  decomposed  through  the  second 
level  of  system  functionality  to  describe  the  capabilities,  operational  activities,  inputs, 
outputs,  controls,  and  mechanisms  that  are  integral  to  the  CUSS  [45],  Scenarios  in  the 
CONOPS  were  traced  through  the  OV-5  to  confirm  that  all  necessary  operational 
activities  were  present  and  no  extra  activities  were  listed. 

The  final  OV  product  created  was  the  Operational  Node  Connectivity  Diagram  or 
OV-2.  This  view  graphically  depicts  the  operational  nodes  or  organizations  that 
exchange  information  with  the  CUSS.  These  information  exchanges  are  called  needlines 
and  they  document  the  requirement  to  pass  information  between  system  and  external 
nodes.  The  OV-2  includes  internal  and  external  operational  nodes,  and  indicates  which 
nodes  conduct  which  operational  activities  in  the  OV-5  [45], 

Once  the  OV-1,  OV-2,  and  OV-5  were  complete,  the  CUSS  team  initiated 
development  of  the  System  View  architecture  products  to  detail  the  physical  systems  and 
components  associated  with  the  nodes,  activities,  needlines,  and  requirements  in  the 
Operational  Views. 

The  first  system  view  created  was  the  System  Interface  Description  or  SV-1.  This 
view  depicts  systems  nodes  and  the  components  resident  at  each  these  nodes.  The  SV-1 
is  derived  from  the  operational  views  in  that  components  and  interfaces  are  chosen  to 
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perform  the  required  operational  activities  and  facilitate  information  exchanges  defined 
by  the  needlines. 

The  second  system  diagram  created  was  the  SV-4  or  System  Functionality 
Description.  This  view  describes  the  system’s  functional  hierarchy  under  its  system 
nodes  and  components.  Each  component  is  decomposed  into  the  specific  system 
functions  that  component  provides. 

Lastly,  the  Operational  Activity  to  Systems  Function  Traceability  Matrix,  or 
SV-5,  was  created  to  map  system  functions  to  operational  activities.  Within  this  view 
each  operational  activity  is  fulfilled  by  one  or  more  system  functions  and  each  system 
function  is  shown  to  support  one  or  more  operational  activities.  This  detailed  matrix 
identifies  components  that  are  potentially  overburdened  or  redundant,  and  gaps  where 
operational  activities  are  not  covered  by  system  functions  within  the  architecture,  ft 
provides  the  link  between  the  System  Views  and  Operational  Views  and  ensures  that  both 
are  consistent. 

Throughout  the  development  of  these  products,  extensive  iteration  and  tracing  of 
operational  threads  provided  by  the  CONOPS  was  conducted  to  explore  required  system 
nodes,  system  activities,  and  information  needs  by  each  component  of  the  conceptual 
architecture.  With  each  iteration,  the  team  gained  a  more  complete  understanding  of  the 
requirements,  functionality,  and  potential  implementation  of  the  CUSS. 

Systems  Engineers  have  many  commercial  software  tools  available  to  create 
architecture  products.  The  CUSS  team  used  Telelogic’s  System  Architect  to  develop  the 
majority  of  the  products  described  in  the  previous  section  and  displayed  in  the 
Appendices.  System  Architect  features  tools  that  can  be  used  to  create  DoDAF 
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architecture  products  and  provides  a  Structured  Query  Language  (SQL)  database  that  the 
software  uses  to  link  these  products  together  [46], 

Test  Architecture 

Concurrent  with  developing  the  architecture  products  for  the  conceptual  system, 
the  CUSS  team  initiated  construction  of  a  representative  flight  test  system  to  explore  the 
capabilities  and  limitations  of  UAS  cooperative  control.  This  system  was  also  used  to 
evaluate  flight  control  and  navigation  algorithms  under  concurrent  development  by  other 
AFIT  research  students. 

Airframe. 

Previous  AFIT  UAS  research  efforts  utilized  the  SIG  Rascal  model  RC  plane 
fitted  with  an  autopilot  and  two  optical  sensors.  This  airframe  is  a  large  scale  radio- 
controlled  airplane  with  a  1 10  inch  wingspan  and  a  four-stroke  power  plant.  The  aircraft 
is  shown  in  Figure  6. 
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Flight  testing  the  SIG  Rascal  required  substantial  overhead  due  to  its  size  and  its 
gas-powered  engine.  Furthermore,  only  two  Rascal  airframes  were  available  for  testing. 
Consequently,  the  team  decided  to  replace  the  SIG  Rascal  with  the  BATCAM  MAV 
shown  in  Figure  7.  This  V-tail  UAV  has  a  21  inch  wing  span  and  is  powered  by  an 
electric  motor.  The  BATCAM  has  a  smaller  logistical  footprint  than  the  Rascal  due  to  its 
small  size  and  electric  propulsion  system.  The  team  acquired  four  BATCAMs  as 
Government  Off-the-Shelf  (GOTS)  hardware.  Though  the  BATCAMs  were  used  for 
most  flight  testing,  the  Sig  remained  compatible  with  the  control  setup  and  was  used  for 
some  single-ship  algorithm  testing. 


Figure  7.  BATCAM  MAV 


Autopilot. 

The  airframes  included  Procerus  Technologies  Kestrel™  autopilots,  shown  in 
Figure  8  [47],  This  is  the  same  flight  control  system  used  in  the  Rascal  for  the  previous 
research  of  Sakyrd  and  Ericson,  Teming,  Vantrease,  and  Hansen  [29;  30;  31;  32],  The 
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autopilot  houses  3 -axis  rate  gyros  and  accelerometers  for  sensing  aircraft  orientation,  as 
well  as  dynamic  and  static  pitot  ports  for  measuring  altitude  and  airspeed.  The  autopilot 
interfaces  with  an  external  Furuno  GH-81  GPS  receiver  for  position  sensing  through  a 
serial  connection  and  provides  control  surface  and  throttle  commands  through  four 
standard  RC  hobby  servo  ports. 


Figure  8.  Procerus  Technologies  Kestrel™  Autopilot  [47] 


Communications. 

The  autopilot  communicates  through  a  serial  cable  or  interface  board  connection 
with  an  external  modem.  The  BATCAMs  came  equipped  with  Aerocomm  AC4868 
modems;  however,  the  team  replaced  them  with  MaxStream  9XTend™  modems.  This 
was  done  to  maintain  compatibility  with  the  ground  station  Commbox  (which  contains  a 
9XTend™  modem).  The  9XTend™  also  has  a  longer  range  than  the  AC4868  and  can  be 
programmed  to  relay  data  packets.  The  modem  transmits  and  receives  data  over  a 
frequency-hopping  spread  spectrum  network  at  900  megahertz  (MHz). 
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Sensors. 


The  BATCAM  airframe  houses  front  and  side  mounted  Charged  Couple  Device 
(CCD)  cameras  in  a  removable  pod  beneath  the  aircraft  body  frame,  shown  in  Figure  9. 
The  measured  Field  of  View  (FOV)  for  this  camera  is  48°  horizontal  by  40°  vertical.  The 
center  of  the  FOV  for  the  front  camera  is  depressed  49°  from  level,  while  the  side 
camera's  is  depressed  39°.  A  serial  connection  from  the  autopilot  to  a  small  power  and 
control  circuit  board  allows  the  operator  to  switch  between  the  two  cameras.  The  camera 
system  can  be  set  to  transmit  video  data  on  one  of  four  frequencies  between  2.4  and  2.5 
gigahertz  (GHz). 


Figure  9.  BATCAM  CCD  Cameras  and  Camera  Pod 
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Ground  Control  Hardware  and  Software. 

The  primary  operator  interface  is  the  Virtual  Cockpit™  software  provided  by 
Procerus  [47].  An  example  of  the  interface  is  shown  in  Figure  10.  It  allows  the  operator 
to  create  and  modify  waypoints,  save  them  to  a  flight  plan,  and  upload  them  to  the 
aircraft.  The  operator  can  monitor  and  control  multiple  aircraft  with  the  software, 
including  changing  the  navigation  mode,  commanded  waypoint,  and  sensor  of  interest. 
The  operator  can  also  send  manual  mode  commands  through  keystrokes  or  an  attached 
game  control  pad.  Virtual  Cockpit™  also  provides  a  video  display  window  that 
interfaces  with  a  video  capture  device  on  the  host  system  to  display  sensor  data.  The 
team  installed  the  software  on  a  Dell  Precision  M6300  laptop. 


Figure  10.  Virtual  Cockpit™  User  Interface 
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The  operator  controls  Kestrel™-equipped  aircraft  through  hardware  and  software 
produced  by  Procerus.  The  Procerus  Commbox  [47],  shown  in  Figure  11,  contains  a 
MaxStream  9XTend™  Modem  connected  to  an  interface  board.  It  has  an  external 
coaxial  connection  for  a  radio  frequency  (RF)  antenna,  and  an  external  serial  connection 
to  interface  with  the  ground  station  computer.  The  team  used  a  serial-to-Universal  Serial 
Bus  (USB)  cable  to  connect  the  Commbox  with  the  laptop.  The  Commbox  has  a 
composite  video  pass  through  that  can  overlay  telemetry  data  on  the  video  signal.  It  can 
also  connect  to  an  external  GPS  receiver,  providing  home  station  position  data  to  the 
control  software. 


Figure  11.  Procerus  Technologies  Commbox  [48] 


Video  Capture  Hardware. 

The  team  set  up  a  robust  system  to  receive,  display,  and  record  video  signals  from 
four  aircraft  simultaneously,  depicted  in  Figure  12.  Two  2.4  GHz  omni-directional 
antennas  oriented  90°  to  each  other  (for  polarity  diversity)  received  the  video  signals  from 
the  BATCAMs.  Each  antenna  was  attached  to  a  4-way  RF  power  divider  to  send  the 
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video  signals  to  separate  receivers.  Each  power  divider  was  connected  to  four  2.4  GHz 
video  receivers,  each  set  to  one  of  the  four  BATCAM  video  transmission  frequencies. 
The  video  receivers  output  composite  video  signals  in  National  Television  System 
Committee  format. 


Figure  12.  Video  Capture  Equipment  Setup 
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Each  pair  of  receivers  operating  at  the  same  frequency  (but  attached  to  different 
antennas)  had  their  video  signals  routed  through  an  Oracle  dual-diversity  video 
controller.  The  controller  automatically  switches  to  obtain  the  best  available  video  signal 
from  the  two  receivers  on  each  frequency,  effectively  providing  a  spatial  and  polarity 
diversified  system. 

The  four  Oracle  controllers  were  connected  to  a  quad  video  switcher.  This  device 
combined  the  four  signals  onto  one  display,  as  shown  in  Figure  13.  The  operator  can 


Figure  13.  Quad  Video  Display 
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select  between  displaying  one  signal,  all  four,  or  two  signals  in  a  picture-in-picture 
format.  The  video  signal  from  the  quad  switcher  was  sent  to  a  Pioneer  DVR-533H  digital 
video  recorder  (DVR)  for  recording,  as  well  as  an  AVerMedia  DVD  EZMaker  USB  Plus 
external  video  capture  device  connected  to  the  laptop  by  a  USB  cable.  The  Virtual 
Cockpit™  software  interfaced  with  the  video  capture  device  so  the  operator  could  display 
the  quad  video  signal  on  the  laptop. 

Control  Algorithm  Interface. 

With  the  help  of  2nd  Lieutenant  Jared  Yates  and  Capt  Chris  Booth,  the  team 
developed  two  separate  software  interfaces  to  allow  a  control  algorithm,  written  in 
MATLAB®  code,  to  interface  with  Virtual  Cockpit™.  One  interface  was  developed  for 
Capt  Booth's  algorithm  [34]  to  converge  multiple  UAVs  on  a  single  target,  and  the  other 
was  developed  for  Austin  Smith's  collision  avoidance  algorithm  [36].  These  software 
interfaces  were  written  in  C++,  using  Microsoft  Visual  Studio,  based  on  the  software 
development  kit  provided  by  Procerus  for  use  with  Virtual  Cockpit™. 

Each  software  interface  interacts  with  Virtual  Cockpit™  via  a  Transport  Control 
Protocol/Intemet  Protocol  (TCP/IP)  socket  connection.  Capt  Booth  and  Mr.  Smith,  who 
used  the  CUSS  as  a  test-bed,  wrote  their  control  algorithms  in  MATLAB®  code.  This 
MATLAB®  code  was  compiled  into  a  dynamic  link  library  (DLL)  file  that  was  included 
in  the  C++  code. 

Upon  launching  each  software  interface,  the  program  established  a  socket 
connection  with  the  Virtual  Cockpit™  software  already  running  in  the  background.  The 
interface  program  would  then  copy  all  relevant  telemetry  data  packets  sent  from  the 
autopilots  to  Virtual  Cockpit™.  Based  on  the  needs  of  each  user,  the  interface  program 
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would  extract  specific  data  from  each  packet  and  copy  this  data  into  variables  that  were 
either  displayed  in  the  graphical  user  interface,  used  as  inputs  to  the  control  algorithm,  or 
both.  Based  on  the  output  of  the  control  algorithms,  the  interface  program  would  then 
generate  control  packets  for  Virtual  Cockpit™  to  send  them  to  one  or  more  autopilots, 
directing  each  affected  aircraft  to  execute  the  flight  plan  or  control  commands  dictated  by 
the  user's  algorithm. 

LCDR  Sakryd  and  Capt  Ericson  developed  a  similar  user  interface  for  their  thesis 
work  [29].  They  based  their  interface  on  a  Model- View-Controller  architecture, 
dedicated  specifically  for  the  purpose  of  tracking  a  single  fleeting  target.  Rather  than 
basing  the  interface  for  the  CUSS  on  the  Fleeting  Target  Controller  program,  the  team 
decided  that  a  simpler  interface  developed  from  the  Virtual  Cockpit™  software 
development  kit  would  be  better  suited  for  each  individual  project  that  it  was  intended  to 
support.  The  two  interfaces  used  were  based  on  Procerus'  software  development  kit  and 
contained  a  significant  amount  of  shared  code,  but  each  algorithm  was  unique  enough  in 
purpose  to  develop  different  programs  with  user  interfaces  tailored  specifically  towards 
each  algorithm. 

Hardware  and  Software-in-the-Loop  Simulation. 

The  flight  test  setup  was  augmented  by  a  configuration  allowing  the  team  to 
perform  software-in-the-loop  (SIL)  and  hardware-in-the-loop  (HIL)  testing  in  the 
laboratory.  The  Aviones  UAV  Flight  Simulator  software  was  the  primary  facilitator  for 
SIL  and  HIL  testing.  Aviones  is  an  open  source  research  tool  developed  by  the  Brigham 
Young  University  Human  Centered  Machine  Intelligence  and  Multiple  Agent  Intelligent 
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Coordination  and  Control  laboratories  [49],  Procerus  Technologies  provided  DLL  files 
for  using  Aviones  with  the  Virtual  Cockpit™  and  Kestrel™  systems. 

In  SIL  mode,  Aviones  simulated  the  aircraft  physics.  It  also  simulated  autopilot 
control  loops  through  the  Procerus  DLL  files.  Aviones  communicated  with  Virtual 
Cockpit™  through  a  TCP  connection,  simulating  the  communication  path  through  the 
Commbox  and  aircraft  modem.  Aircraft  physics  parameters  and  simulated  winds  could 
be  changed  by  modifying  variables  in  text  files  Aviones  reads  upon  initialization.  Figure 
14  depicts  the  SIL  setup. 


Figure  14.  Software-in-the-Loop  Setup 


For  HIL  mode,  Aviones  simulated  aircraft  physics  only.  The  Kestrel™  autopilot 
received  simulated  sensor  inputs  (gyro,  accelerometer,  and  pitot/static)  and  GPS  data 
from  Aviones  through  two  USB-to-serial  connector  cables.  It  generated  its  own  control 
commands  which  it  passed  back  to  Aviones  through  one  of  the  USB-to-serial  cables.  The 
autopilot  communicated  with  Virtual  Cockpit™  through  the  Commbox,  as  it  would  in 
actual  flight.  Figure  15  depicts  the  HIL  setup. 
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Figure  15.  Hardware-in-the-Loop  Setup 


Flight  Testing 

Due  to  current  Federal  Aviation  Administration  (FA A)  limitations  that  restrict  all 
UAV  flight  test  activities  by  U.S.  Government  agencies  within  the  National  Airspace 
System  (NAS),  the  team  was  required  to  use  restricted  airspace  for  all  flight  tests.  To 
comply  with  this  requirement,  the  closest  restricted  airspace  to  AFIT  suitable  for  UAV 
testing  is  the  Camp  Atterbury  Joint  Maneuver  Training  Center  located  near  Edinburgh, 
Indiana.  An  overview  of  the  testing  grounds  is  shown  in  Figure  16.  Camp  Atterbury  is 
located  about  three  hours  from  Dayton,  Ohio  and  has  been  used  extensively  by  both 
AFRL  and  AFIT  to  conduct  UAV  flight  tests  and  evaluation  of  advanced  navigation 
technologies  [31].  To  prepare  for  each  flight  test,  the  team  contacted  Camp  Atterbury 
and  coordinated  the  use  of  the  aircraft  parking  ramp  next  to  the  Camp  Atterbury  runway 
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and  control  tower.  This  communication  was  necessary  to  ensure  both  airspace  and 
frequency  deconfliction  during  all  periods  of  active  UAV  flight  testing. 


Figure  16.  Camp  Atterbury  Joint  Maneuver  Training  Center 


Prior  to  each  flight  test,  the  team  briefed  proposed  flight  test  activities  to  a 
Technical  Review  Board  (TRB)  and  concurrently  briefed  a  Safety  Review  Board  (SRB) 
to  ensure  both  the  team’s  test  objectives  and  safety  procedures  were  sufficient.  In 
addition  to  the  TRB/SRB,  the  team  prepared  flight  test  cards  that  detailed  the  specific 
steps  and  procedures  to  be  executed  during  the  flight  test  and  developed  checklists  for 
inventorying  and  setting-up  ground  and  flight  test  equipment.  Team  members  also 
conducted  extensive  ground  based  dry  runs  of  each  test  event  to  ensure  both  personnel 
and  equipment  used  during  the  flight  test  were  available  and  fully  operational.  Personnel 
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from  Cooperative  Engineering  Services  Incorporated  (CESI),  a  company  contracted  by 
AFIT’s  Advanced  Navigation  Technology  laboratory,  assisted  the  team  in  ground  and 
flight  testing  by  providing  ground  support,  RC  pilot  expertise,  and  the  use  of  their  20  foot 
self-contained  and  enclosed  operations  trailer  from  which  to  conduct  flight  test  activities. 
Once  the  dry  run  was  satisfactorily  completed,  the  team  loaded  the  trailer  with  all 
required  equipment  and  necessary  spare  parts  for  the  flight  test. 

On  the  day  of  a  test,  the  team  would  arrive  at  Camp  Atterbury  and  check-in  with 
Range  Control  and  the  Airfield  to  pick  up  radios  to  maintain  communications  throughout 
the  day  and  to  see  if  there  were  any  last  minute  range  restrictions  or  current  operations 
that  would  impact  the  flight  test.  Once  this  was  complete,  the  team  would  proceed  to  the 
aircraft  parking  ramp  and  begin  setting  up  the  flight  test  equipment  and  operations  trailer 
in  accordance  with  the  schematic  in  Figure  17. 
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Figure  17.  Flight  Test  Hardware  Schematic 


Figure  18,  Figure  19,  and  Figure  20  show  the  fully  assembled  test  ground  station 
equipment  within  the  CESI  operations  trailer. 
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Figure  18.  Laptop  and  Monitor 


Figure  19.  Quad  Switcher,  DVR,  Wall  Monitor,  and  Commbox 
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Figure  20.  Video  Receivers  and  Dual  Diversity  Controllers 

All  antennas,  to  include  the  Commbox,  GPS  receiver,  and  analog  sensor  receiver 
antennas,  were  externally  mounted  to  the  mast  structure  at  the  front  of  the  trailer  as 
shown  in  Figure  2 1 .  Each  aircraft  was  prepared  for  pre-flight  check  out  and  operation  in 
accordance  with  checklists  produced  by  the  team.  Once  the  trailer  and  UAV’s  were  fully 
assembled,  all  team  members  met  for  a  safety  brief  and  review  of  the  flight  test  objectives 
for  the  day.  Upon  completion  of  these  briefings,  the  team  would  commence  testing. 
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Figure  21.  Trailer  Mast  and  Antennas 


Over  the  course  of  this  research,  the  CUSS  team  conducted  five  full  days  of  flight 
testing  over  a  period  of  six  months.  The  first  two  flight  tests  occurred  during  September 
and  October  of  2008  and  allowed  to  team  to  become  comfortable  with  BATCAM  launch 
and  recovery  operations  and  begin  to  understand  the  individual  flight  characteristics  of 
each  BATCAM  vehicle  flown.  To  ensure  optimal  integration  of  the  Kestral™  autopilot 
with  the  BATCAM,  an  extensive  tuning  process  was  followed  to  ensure  proper  UAV 
control.  During  autopilot  tuning,  the  trim  settings  of  each  BATCAM  were  determined  in 
addition  to  tuning  the  inner  and  outer  control  loops.  Waypoint,  loiter  navigation,  and 
other  user  defined  setting  were  also  tuned  to  ensure  effective  operation  and  control  of  the 
BATCAMs.  Once  the  team  was  satisfied  with  the  tuning  parameters,  these  settings  were 
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uploaded  to  each  aircraft  and  then  test  flown  to  ensure  nominal  operation.  This  tuning 
process  also  allowed  the  team  to  gain  extensive  experience  with  operating  the  Virtual 
Cockpit™  interface  and  to  demonstrate  the  video  downlink  capability  of  each  vehicle. 

On  the  second  day  of  flight  testing,  the  team  managed  to  launch  and  simultaneously  fly 
two  aircraft,  a  first  for  AF1T. 

The  next  two  flight  tests  occurred  in  November  and  December  of  2008.  The 
primary  purposes  of  these  tests  were  to  simultaneously  fly  up  to  four  BATCAMs  and 
demonstrate  the  capability  of  simultaneously  receiving  video  feeds  from  each  vehicle. 

The  first  of  these  two  flight  dates  enabled  the  team  to  begin  testing  Capt  Farrell’s  Sensor 
Aimpoint  algorithm  [33]  and  Capt  Booth’s  Cooperative  Control  algorithm  [34],  On  the 
first  of  these  dates,  the  team  successfully  launched  and  simultaneously  flew  four 
BATCAMs  in  a  racetrack  pattern  at  Camp  Atterbury.  The  team  also  demonstrated 
cooperative  control  behavior  during  the  December  flight  test  through  the  use  of  Capt 
Booth’s  algorithm  that  generated  navigation  waypoints  and  then  commanded  two  or  three 
BATCAM  UAVs  to  fly  to  the  generated  waypoints  [34],  The  Sig  Rascal  was  also  used 
during  the  December  flight  test  to  gather  data  for  Capt  Farrell’s  algorithm  from  a 
different  aircraft  [33], 

The  final  flight  test  occurred  in  February  of  2009.  The  purpose  of  this  test  was  to 
conduct  further  evaluation  of  Capt  Booth’s  Cooperative  Control  algorithm  [34],  initial 
flight  testing  of  Mr.  Smith’s  Collision  Avoidance  algorithm  [36],  benchmark  flight 
testing  of  the  endurance  of  the  a  larger  battery  for  the  BATCAMs,  and  an  initial 
evaluation  of  the  time  required  to  recover  and  re-launch  a  UAV  in  support  of  an  extended 
mission. 
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Technological  Risks 


During  the  development  of  the  conceptual  architecture  and  flight  testing  of  the 
BATCAMs,  the  team  identified  a  number  of  limitations,  issues,  and  risks  that  could 
impact  the  operational  future  of  cooperative  control  systems.  The  team  will  discuss  and 
evaluate  these  risks  in  the  Results  section  of  this  thesis  and,  where  applicable,  propose 
mitigation  strategies  to  reduce  or  eliminate  these  risks.  Some  risks  or  issues  may  be 
outside  the  scope  of  this  thesis  and  will  be  proposed  as  follow-on  or  future  research  work. 
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IV.  Results 


Concept  of  Operations 


When  presented  with  the  problem  of  obtaining  real-time  ISR  from  a  portable 

system  with  links  to  outside  support  elements,  the  team  first  researched  current  fielded 

capabilities  and  perceived  capability  gaps.  The  team  also  researched  the  work  of 

previous  groups  whose  theses  focused  on  similar  areas. 

The  team  then  developed  a  CONOPS,  shown  in  Appendix  B,  describing  what 

capabilities  the  system  would  address,  what  missions  the  system  would  fulfill,  and  what 

functions  the  system  would  perform.  The  initial  focus  was  on  a  few  proposed  operational 

scenarios.  In  documenting  these  scenarios,  the  team  first  constructed  the  sequenced 

actions  of  various  missions  that  the  system  would  be  expected  to  perform.  An  example 

of  an  employment  scenario  from  the  CONOPS  is  Surveil  a  Stationary  Target : 

"A  user  wishes  to  surveil  a  stationary  target.  The  user  creates  a  mission 
plan,  deploys  the  CUSS,  and  prepares  the  UAVs  for  flight.  Once  the 
mission  plan  is  complete  and  approved,  the  plan  is  transmitted  to  the 
UAVs  via  the  [Ground  Communication  Hardware  (GCH)].  After  UAS 
deployment,  the  [Computing  Device  (CD)]  interfaces  with  the  UAV 
autopilots  to  guide  the  UAVs  to  the  target  location.  Upon  reaching  the 
target  location,  the  UAVs  perform  a  search,  acquire  the  target,  and  set  up  a 
loiter  flight  pattern  in  accordance  with  the  mission  plan  or  as  designated 
by  the  user.  The  UAVs  maintain  surveillance  and  sensor  coverage  of  the 
target.  At  the  end  of  the  mission,  the  UAVs  are  re-tasked  or  returned  to 
their  designated  recovery  location.” 

While  over  the  designated  target,  the  user  may  change  the  UAV  and 
sensor  parameters  to  minimize  the  chance  of  detection  of  the  UAVs  or  to 
obtain  better  sensor  geometry  or  resolution  of  the  target.  These  changes 
can  be  accomplished  either  through  sensor  control  commands,  UAV  flight 
commands  or  both.  Depending  on  the  type  and  scope  of  changes  made  by 
the  user,  a  new  mission  plan  may  be  generated  and  sent  to  the  UAVs." 
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The  employment  scenarios  section  of  the  CONOPS  also  addresses  the  following 
scenarios:  Surveil  a  Moving  Target ;  Reconnoiter  Ahead  of  a  Moving  Target,  Provide 
Surveillance  of  a  Series  of  Waypoints',  Conduct  a  Broad  Area  Search',  and  Conduct  a 
Search  for  a  Target. 

After  laying  out  these  employment  scenarios,  the  group  abstracted  a  number  of 

functions  common  to  multiple  tasks,  which  are  listed  as  general  system  functions  of  the 

sequenced  actions  section.  An  example  of  a  general  system  function  is  Plan  Mission : 

"The  user  begins  the  development  of  a  mission  plan  by  taking  user  defined 
inputs  such  as  ISR  data,  mission  tasking,  mission  data,  airspace  control 
measures,  target  list,  UAS  flight  status,  and  an  asset  list  and  entering  these 
into  CUSS  software  hosted  on  the  Computing  Device  (CD).  The  software 
then  develops  and  generates  a  mission  plan  that  when  executed,  will 
achieve  the  overall  mission  objectives.  Once  the  mission  plan  is  complete, 
the  CD  sends  the  information  via  the  Ground  Communications  Hardware 
(GCH)  to  the  UAS.  The  mission  plan  is  typically  uploaded  to  each  UAV 
before  launch  but  real-time  updates  to  the  mission  plan  can  be  forwarded 
to  UAVs  at  any  time  after  launch." 

The  general  systems  functions  section  of  the  CONOPS  also  addresses  the 
following  scenarios:  Deploy  System;  Replan  Mission;  Manage  the  UA  Vs;  Control 
Sensors;  Manage  Surveillance  Data;  Manage  Health  and  Status  of  UA  Vs;  Recover  the 
System;  and  Conduct  Post  Mission  Actions.  From  these  scenarios,  the  team  built  a 
conceptual  architecture  for  the  CUSS. 


Conceptual  Architecture 


AV-1. 


The  A  V-l  Overview  and  Summary  Information  is  shown  in  Appendix  C.  The 
CUSS  is  a  composite  architecture  of  systems,  components,  and  communication  links  that 
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enables  UAVs  to  work  in  cooperative  formations.  By  exploiting  the  capabilities  offered 
through  cooperative  control,  the  UAS  can  accomplish  a  wide  variety  of  missions  faster 
and  more  effectively  than  is  possible  with  a  single  UAV. 

AV-2. 

All  terms  associated  with  the  conceptual  architecture  are  captured  in  the  A  V-2 
Integrated  Dictionary.  Terms  are  listed  in  alphabetical  order  in  Appendix  D,  and  include 
the  description,  type,  and  associated  view(s).  This  product  provides  textual  definitions 
for  the  elements  of  the  architecture  products,  and  ensures  that  terms  are  not  used  to 
describe  multiple  concepts. 

OV-1. 

Several  key  employment  scenarios  from  the  CONOPS  and  system  characteristics 
were  captured  in  the  High-level  OV-1  Operational  Concept,  in  Figure  22  below.  One  key 
aspect  of  the  system  depicted  is  that  CUSS  Airborne  Control  Unit  components  are  not 
specific  to  a  single  type  or  family  of  UAVs.  The  system  is  scalable  from  man-packable 
variants  up  to  larger  and  longer  endurance  platforms  on  the  scale  of  the  Predator  and 
Global  Hawk  UAVs.  Similarly,  the  Ground  Control  Unit  hardware  and  software  is 
scalable  from  a  single  user  equipped  with  a  laptop,  to  a  robust  control  center  with  desktop 
computers  and  multiple  monitors.  The  OV-1  shows  two  methods  of  extending 
communications  range  to  beyond  line-of-sight:  relaying  data  through  CUSS  equipped 
UAVs,  and  sending  data  through  a  dedicated  communications  relay.  Also,  it  depicts  links 
to  external  systems  like  GPS  and  Theater  HQ  which  provides  C2ISR. 
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Figure  22.  CUSS  OV-1  Operational  Concept 


The  OV-1  also  shows  the  system  performing  a  variety  of  missions  from  the 
CONOPS.  The  first  employment  scenario  is  the  small  unit  or  tactical  operator  requiring 
persistent  surveillance  of  a  building  or  target  of  interest.  This  forward-based  operator 
may  receive  taskings  from  Theater  Headquarters  (HQ)  or  surveillance  requirements  may 
be  self-generated.  Once  tasked,  the  operator  creates  a  mission  plan  with  the  CUSS 
Ground  Control  System,  uploads  the  mission  plan  to  the  Airborne  Control  Units  onboard 
the  UAVs  and  launches  each  aircraft.  Once  airborne,  the  UAV  travels  to  its  designated 
target  location  using  precision  navigation  from  GPS  satellites  and  initiates  data  collection 
once  it  reaches  the  desired  target.  Control  of  the  UAV  sensors  may  be  automatic  in 
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accordance  with  the  mission  plan,  or  manually  controlled  by  the  operator.  The  airborne 
platforms  are  in  constant  communication  with  the  CUSS  ground  station  and  with  each 
other  platform  in  the  formation.  This  ensures  system  awareness  and  precise  positioning 
relative  to  the  target  and  other  platforms  in  accordance  with  the  mission  plan.  The 
system  exhibits  cooperative  behavior  by  allocating  ISR  data  collection  requirements 
among  the  vehicles  to  maximize  data  collection.  As  intelligence  is  collected,  the  operator 
can  view  the  data  real-time  and  also  export  the  surveillance  product  via  satellite 
communications  (SatCom)  link  back  to  Theater  HQ,  a  Forward  Operating  Base  (FOB),  or 
higher  command  authorities  as  required. 

Another  operational  thread  shown  in  the  OV-1  is  the  ability  to  provide  route 
surveillance  along  Main  Supply  Routes  (MSRs)  and  Lines  of  Communication  (LOCs)  for 
convoy  operations.  In  this  scenario,  the  UAVs  are  tasked,  launched,  and  then  directed  to 
intercept  the  designated  convoy  by  personnel  from  a  FOB.  Due  to  the  long-range  nature 
of  this  operation,  CUSS  equipped  platforms  can  function  as  relays  to  extend  UAV  range 
when  operating  beyond  line-of-sight  from  the  launch  or  control  location.  The  CUSS  is 
equipped  with  a  beacon  following  capability  that  enables  the  UAVs  to  adjust  their 
positions  based  on  the  behavior  of  the  convoy.  At  the  end  of  the  mission,  the  UAVs  are 
directed  to  return  to  their  recovery  location  at  the  FOB. 

The  last  operational  concept  displayed  in  OV-1  is  the  use  of  a  UAS  to  provide 
perimeter  surveillance  of  a  FOB.  The  UAVs  can  be  tasked  by  the  user  to  fly  pre¬ 
determined  waypoints  that  provide  situation  awareness  and  identification  of  threats 
outside  the  base  wire.  This  mission  would  likely  specify  optimal  spacing  among 
available  assets  to  maximize  re-visit  time  along  all  areas  of  the  perimeter.  As  real-time 
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threats  or  targets  are  identified,  the  user  can  manually  re-task  a  platform  within  the 
formation  to  investigate  the  threat.  Remaining  UAVs  would  adjust  formation  spacing  to 
optimize  re-visit  time.  Once  the  re-tasked  UAV  has  completed  its  mission,  the  user  can 
direct  a  formation  re-join,  and  formation  spacing  would  once  again  adjust  to  optimize 
revisit  time.  Data  collected  in  this  scenario,  like  previous  scenarios,  is  available  to 
Theater  HQ  and  other  distributed  users  as  required. 

OV-5. 

After  completing  the  OV-1,  the  team  began  the  process  of  understanding  the 
discrete  operational  activities  that  the  system  must  perform  to  execute  the  wide  variety  of 
mission  threads  and  alternate  flows  identified  within  the  CONOPS.  The  team  began 
functional  decomposition  by  identifying  the  external  systems  with  which  the  CUSS  must 
interface  to  provide  a  cooperative  control  capability.  This  analysis  provided  systems 
boundaries  and  scoped  the  complexity  of  the  effort.  The  External  Systems  Diagram, 
shown  in  Figure  23,  details  each  external  system  that  either  sends  to  or  exchanges 
information  with  the  CUSS  to  accomplish  its  core  activity  of  Provide  Surveillance  for 
system  users. 


54 


A-0  Provide  Surveillance  External  Systems  Diagram  (OV-05  Activity  Model) 
System  Architect 
Mon  Jan  26,  2009  14:29 
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Figure  23.  CUSS  A-0  External  Systems  Diagram 

The  primary  interfaces  required  for  the  Provide  Surveillance  operational  activity 
include  the  following:  receiving  precision  navigation  data  from  the  Provide  PNT 
operational  activity;  receiving  mission  taskings  and  relevant  information  related  to 
mission  planning  and  execution  from  the  Provide  C2ISR  (Command,  Control, 
Information,  Surveillance,  and  Reconnaissance)  operational  activity;  interfacing  with  the 
Provide  Surveillance  Platform  operational  activity  to  control  vehicles  and  sensors; 
interfacing  with  the  Provide  Surveillance  Platform  operational  activity  to  capture  mission 
data;  interaction  with  the  Provide  Surveillance  Platform  operational  activity  to  handle 
launch,  recovery,  and  maintenance  activities  associated  with  the  aerial  platform  and  on- 
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board  sensors;  and,  if  conducting  a  beacon  following  mission,  receive  a  reference  beacon 
signal  from  the  Provide  Reference  Location  operational  activity.  Inputs,  Controls, 
Outputs,  and  Mechanisms  (ICOMs)  flow  between  each  of  these  operational  activities  to 
provide  the  interactions  necessary  to  achieve  desired  functionality  for  a  variety  of  CUSS 
missions. 

Once  the  CUSS  was  sufficiently  bounded  by  its  connections  with  external 
systems,  the  team  decomposed  the  Provide  Surveillance  operational  activity  to  the  second 
level  of  functionality,  ensuring  each  aspect  of  the  systems  activities,  interactions,  and 
capabilities  were  fully  understood.  Beginning  with  the  employment  scenarios  located  in 
Appendix  B  of  the  CONOPS,  the  team  traced  each  mission  thread  from  initiation  through 
completion,  capturing  all  required  activities.  This  mission  tracing  revealed  a  more 
complete  understanding  of  mission  needs  and  verified  the  CUSS  was  capable  of 
providing  the  required  functionality  for  each  scenario.  To  illustrate  this  process,  the  first 
employment  scenario  within  the  CONOPS,  Surveil  a  Stationary  Target ,  will  be  traced 
through  the  CUSS  conceptual  architecture.  During  this  illustration,  the  primary  flow  with 
only  a  few  contingencies  will  be  followed;  though,  an  extensive  number  of  alternate 
flows  are  possible  within  this  employment  scenario. 

Using  the  AO  level  of  the  OV-5  decomposition  for  the  CUSS  found  in  Figure  24, 
there  are  four  first-level  operational  activities  required  to  Provide  Surveillance :  Plan 
Mission,  Manage  UA  Vs,  Control  Sensors,  and  Manage  Surveillance  Data. 
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Figure  24.  OV-5  AO  Provide  Surveillance 

Within  this  employment  scenario  the  target  is  a  fixed  facility  that  requires  ISR 
collection.  The  first  step  in  this  mission  is  for  the  C2ISR  Node  to  task  a  forward- 
deployed  operator  to  provide  persistent  surveillance  on  this  facility.  This  notification  and 
collection  requirement  would  likely  come  through  a  SatCom  link. 

Beginning  with  the  A1  Plan  Mission  operational  activity  in  Figure  25,  the 
operator  initializes  his  CUSS  and  receives  target  coordinates,  the  types  of  sensor  data  to 
be  collected,  the  date  and  times  of  required  collection,  and  other  relevant  data  associated 
with  the  mission  tasking  such  as  historical  ISR  data,  weather  conditions,  threats  over  the 
target  area,  and  airspace  restrictions.  The  operator  also  obtains  a  list  of  available  UAV 
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and  sensor  assets  in  addition  to  PNT Data  from  GPS  satellites  to  determine  the  home 


location. 


Figure  25.  CUSS  OV-5  A1  Plan  Mission 


The  CUSS  consumes  this  data  by  stepping  through  the  second  tier  operational 
activities  of  Plan  Mission:  Select  Resources,  Set  Constraints,  Set  Mission  Parameters, 
and  Generate  Mission  Plan.  After  comparing  mission  tasking  against  available 
resources,  constraints,  and  parameters,  the  CUSS  would  create  a  Mission  Plan  that  fully 
meets  the  objectives  of  the  original  tasking.  If  at  any  point  the  system  determines  that 
there  is  a  constraint  that  conflicts  with  Mission  Tasking,  a  Planning  Alert  is  sent  to  the 
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operator.  The  operator  can  acknowledge  and  override  the  alert  or  modify  a  parameter  of 
the  Mission  Plan  to  address  the  alert. 

Once  the  Mission  Plan  is  complete,  flight  assets  are  readied  and  launched  at  the 
time(s)  specified  by  the  plan.  After  each  UAV  is  airborne  and  enroute  to  the  target,  the 
operator  transitions  to  ensuring  the  proper  management  and  operation  of  the  UAVs. 
Within  the  A2  Manage  UA  Vs  operational  activity  found  in  Figure  26,  the  CUSS  uses  PNT 
Data  and  Telemetry  Data  received  from  the  UAVs  to  continuously  evaluate  the  overall 
Mission  Status  in  comparison  with  the  Mission  Plan  and  to  monitor  individual  UA  V 
Flight  Status.  During  all  active  flight  times,  mission  and  flight  status  information  is 


Figure  26.  CUSS  OV-5  A2  Manage  UAVs 
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continuously  relayed  to  the  C2ISR  Node  to  provide  situational  awareness  in  addition  to 
forwarding  collected  ISR  Data  once  the  UAS  reaches  the  target  facility.  Because  the 
Mission  Plan  is  a  static  entity,  changes  in  UAV  flight  performance,  user  inputs,  or 
Mission  Tasking  may  require  the  creation  of  a  new  Mission  Plan. 

During  persistent  surveillance  around  the  facility  under  observation,  the  CUSS 
monitors  the  precise  position  of  each  UAV  within  the  formation  in  relation  to  the  target 
position.  It  generates  a  desired  formation  position  for  each  UAV  to  optimize  parameters 
such  as  spacing  between  aircraft  and  sensor  orientation  with  respect  to  the  target.  The 
Navigate  UA  Vs  operational  activity  uses  errors  in  the  desired  formation  position  and 
other  constraints  from  the  mission  plan  to  generate  Navigation  Commands  for  each 
individual  airborne  platform.  The  Navigate  UA  Vs  operational  activity  also  adjusts  for 
weather  conditions  such  as  wind  and  for  Sensor  Tracking  Errors  to  maneuver  the  aircraft 
to  keep  the  target  in  the  sensor  FOV.  Navigation  Commands  are  translated  into  UAV 
Control  Commands  to  cause  the  aircraft  to  fly  in  the  desired  manner.  These  UA  V  Control 
Commands  are  then  sent  to  the  UAVs  control  surfaces  and  propulsion  system  to  be  acted 
upon. 

Once  the  UAS  begins  data  collection,  sensor  pointing  and  tracking  become 
paramount.  The  A3  Control  Sensors  operational  activity  found  in  Figure  27  is 
decomposed  into  the  operational  activities  of  Manage  Sensors,  Track  Point  of  Interest 
(POI),  and  Generate  Sensor  Commands.  The  system  uses  these  operational  activities  to 
ensure  optimal  sensor  placement. 
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Figure  27.  CUSS  OV-5  A3  Control  Sensors 

The  CUSS  compares  UA  V Position  and  Orientation  to  Target  Location  data  to 
determine  the  proper  Sensor  Gimbal  Angles  to  keep  the  target  in  the  sensor  FOV.  The 
system  sends  Sensor  Tracking  Error  signals  to  the  Manage  UA  Vs  operational  activity  to 
adjust  UA  V  Orientation,  and  it  uses  Desired  Gimbal  Angle  to  generate  commands  to 
optimally  point  the  sensors.  The  user  also  has  the  ability  to  view  real-time  data  collected 
by  the  sensors  via  the  CUSS  Computing  Device  and  can  make  manual  inputs  that  affect 
both  UAV  positioning  and  sensor  pointing  if  an  object  of  interest  is  detected  and  requires 
further  evaluation.  Additionally,  if  the  system  detects  conditions  that  impact  the  sensor, 
such  as  external  icing,  internal  over-heating,  or  low  voltage  conditions,  the  CUSS  alerts 
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the  user  of  the  condition.  If  pre-determined  fail-safes  are  met,  the  system  autonomously 
generates  Sensor  Management  Commands  to  protect  sensor  assets,  or  these  commands 
can  come  from  user  inputs. 

As  the  UAS  collects  intelligence  on  the  target  facility,  a  key  capability  of  the 
CUSS  is  processing  and  displaying  collected  data  to  distributed  users.  Accordingly,  the 
A4  Manage  Surveillance  Data  operational  activity  in  Figure  28  is  decomposed  into  the 
operational  activities  of  Process  Data,  Record  and  Playback  Data,  and  Produce 
Surveillance  Product. 


Figure  28.  CUSS  OV-5  A4  Manage  Surveillance  Data 
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The  system  provides  the  collected  data  real-time  to  the  operator  via  a  Video 
Display.  Each  UAV  sensor  feed  can  be  viewed  individually  or  as  a  composite  picture  to 
provide  situational  awareness  of  the  entire  facility.  The  system  records  the  sensor  feeds, 
so  that  the  operator  can  review  them  systematically  or  individually  if  the  operator  detects 
an  event  of  interest  within  a  specific  sensor  FOV. 

The  operator  interprets  the  incoming  data,  and  generates  User  Flight  Commands 
and  User  Sensor  Commands  to  affect  the  conduct  of  the  mission  based  on  the  data 
received.  The  system  also  interprets  the  data  to  derive  Target  Location  from  collected 
information  and  associate  Metadata  from  the  aircraft  telemetry  with  the  corresponding 
Video  Display.  The  user  can  input  Metadata  derived  from  the  Video  Display  such  as 
target  identification.  The  recorded  sensor  information  and  generated  Metadata  is  used  to 
create  finished  Surveillance  Products ,  such  as  annotated  imagery,  that  are  exportable  to 
the  C2ISR  Node  and  other  distributed  users  to  evaluate  mission  success  and  create 
requirements  for  subsequent  missions. 

At  the  conclusion  of  the  mission,  the  UAVs  are  directed  to  return  to  their  recovery 
location  in  accordance  with  the  Mission  Plan,  and  navigate  there  through  the  Manage 
UA  Vs  activity.  The  operator  can  then  discontinue  use  of  the  CUSS  until  receipt  of  the 
next  mission  tasking. 

By  tracing  each  of  the  employment  scenarios  in  the  CONOPS  and  alternate  flows, 
the  team  verified  and  refined  required  operational  activities,  capabilities,  and  ICOMs 
integral  to  the  CUSS.  Within  this  breakdown,  general  systems  activities  were  identified 
such  as  system  deployment,  UAS  launch  and  recovery,  mission  re-planning,  and  post¬ 
mission  maintenance  and  repair  which  are  a  recurring  part  of  every  mission.  This  process 
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ensured  the  CUSS  was  robust,  flexible,  and  responsive  to  a  wide  variety  of  potential  user 
needs  and  requirements. 

OV-2. 

After  the  OV-5  was  complete,  the  team  created  the  OV-2  or  Operational  Node 
Connectivity  Description  in  Figure  29.  This  diagram  depicts  each  operational  node  and 
describes  the  primary  information  flows,  or  needlines,  that  exist  between  these  nodes. 
Within  this  figure,  information  flows  can  be  directionally  traced  between  the  originating 
node  and  the  receiving  node.  In  some  cases,  information  may  pass  back  and  forth  such  as 
between  the  CUSS  and  the  UA  V  Sensor  Node.  In  other  cases  information  is 
unidirectional  such  as  the  CUSS  receiving  a  Reference  Tracking  Signal  without  providing 
any  information  back  to  the  Reference  Node  emitting  the  signal.  Each  of  these  nodes 
represents  an  organizational  entity  that  carries  out  the  operational  activities  specified 
within  the  OV-5.  The  corresponding  activities  are  listed  inside  the  node  bubbles  in 
Figure  29. 
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Figure  29.  CUSS  OV-2  Operational  Node  Connectivity  Description 


SV-1. 


The  SV-1  Systems  Interface  represents  a  physical  implementation  of  the  activities 
identified  in  the  operational  views.  The  conceptual  CUSS  is  a  combination  of  hardware 
and  software  components  divided  between  the  Ground  System  Node  and  the  Airborne 
System  Node,  as  depicted  in  Figure  30. 
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CUSS  (SV-01  Systems  Interface) 
System  Architect 
Wed  Feb  04,  2009  13:45 


Figure  30.  CUSS  SV-1  System  Interface  Description 


Within  the  CUSS  Ground  System  Node,  the  primary  CUSS  components  are  the 
Operator,  CUSS  Software,  and  the  Ground  Transceiver.  Components  provided  to  the 
users  that  are  not  part  of  the  CUSS  developed  components  include  the  Computing  Device 
that  runs  the  CUSS  software  and  serves  as  an  interface  between  the  Operator  and 
software,  a  GPS  Receiver  antenna  that  provides  home  station  location  of  the  Computing 
Device,  and  a  Communications  Antenna  that  provides  a  Communications  Link  and  Sensor 
Data  Link  capability  between  the  Ground  System  and  Airborne  System  platforms.  Within 
the  Ground  System,  the  Operator  has  a  two-way  C2  Communications  path  between  the 
C2ISR  Node  to  receive  mission  tasking  and  relay  mission  status  to  higher  command 
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authorities.  The  Computing  Device  also  has  a  two-way  C,2  Link  with  the  C2ISR  Node  to 
receive  Mission  Planning  and  ISR  Alert  Data.  At  any  time,  the  Operator  can  use  the 
Computing  Device  to  interface  with  the  CUSS  components  or  any  of  the  UAS  assets 
under  his  or  her  direction.  All  outgoing  data  from  the  Computing  Device  is  modulated  by 
the  Ground  Transceiver  before  the  Communications  Antenna  forwards  data  to  the 
Airborne  System  platforms  and  sensors.  Communications  data  coming  from  these 
platforms  is  also  demodulated  by  the  Ground  Transceiver  before  being  received  by  the 
Computing  Device. 

Within  the  Airborne  Systems  Node,  only  the  Airborne  Control  Unit,  or  autopilot, 
and  the  Airborne  Transceiver  are  CUSS  provided  components.  Other  system 
components  that  are  provided  to  CUSS  users  and  are  not  CUSS  specific  components 
include  the  Air  Vehicle,  Sensor  Package,  and  Communications  Antenna  resident  on  the 
platform.  The  CUSS  Airborne  Control  Unit  is  contained  within  the  Air  Vehicle.  It  is 
capable  of  providing  flight  control  information  to  the  platform  and  accepting  health  and 
status  data  from  the  platform.  The  Air  Vehicle  is  responsible  for  receiving  a  GPS  Signal 
and  passing  PNT Data  to  the  Airborne  Control  Unit.  Additionally,  all  sensor  control  and 
status  information  is  routed  through  the  Airborne  Control  Unit.  Any  data  going  from  the 
Airborne  Control  Unit  or  Sensor  Package  back  to  the  Ground  System  or  relayed  to 
another  Airborne  System  is  modulated  by  the  Airborne  Transceiver  and  sent  through  the 
Communications  Antenna  on  the  Airborne  System.  Similarly,  data  received  by  this 
antenna  is  routed  through  the  Airborne  Transceiver  and  de-modulated. 
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SV-4. 


After  the  SV-1  was  completed,  the  team  evaluated  the  architecture  to  identify 
system  functions  that  are  specific  to  CUSS  developed  components.  For  the  CUSS  SV-4 
Functional  Decomposition  found  in  Figure  31,  the  team  began  with  the  Ground  Systems 
and  the  Airborne  Systems  Nodes  and  identified  each  component  within  the  respective 
node.  The  CUSS  Ground  Node  contains  the  Operator,  Ground  Transceiver,  and  CUSS 
Software.  The  Airborne  Node  contains  the  Airborne  Control  Unit  and  the  Airborne 
Transceiver. 


Figure  31.  CUSS  SV-4  System  Functionality  Description 
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This  hierarchy  was  further  decomposed  by  identifying  the  system  functions, 
requirements,  and  information  flows  specific  to  each  of  these  components.  By  tracing 
mission  threads  derived  from  the  CONOPS,  the  team  verified  that  each  component 
provided  the  required  functionality  to  execute  a  wide  array  of  operational  missions. 

SV-5. 

After  the  Systems  Functionality  Description  was  finalized,  the  team  created  the 
final  architecture  product  for  the  conceptual  CUSS,  the  SV-5  Operational  Activity  to 
System  Function  Traceability  Matrix  in  Table  1 .  This  matrix  takes  the  system  functions 
identified  in  the  SV-4  and  maps  them  to  the  operational  activities  identified  in  the  OV-5. 
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Table  1.  CUSS  SV-5  Activity  to  Function  Traceability  Matrix 


SV-5 

i 

Si 

SYSTEM  FUNCTION  £  u 

A1  Plan  Mission 

A2  Manage  UAVs 

A3  Control  Sensors 

A4  Manage 

Surveillance  Data 

Al.l  Select 

Resources 

A1.2  Set  Constraints 

A1.3  Set  Mission 

Parameters 

A1.4  Generate 

Mission  Plan 

A2.1  Conduct  Mission 

A2.2  Track  Reference 

A2.3  Manage 

Formation 

A2.4  Navigate  UAVs 

A2.5  Generate 

Control  Commands 

A3.1  Manage  Sensors 

A3. 2  Track  Point  Of 

merest 

A3.3  Generate  Sensor 

Commands 

A4.1  Process  Data 

A4.2  Record  and 

Playback  Data 

A4.3  Interpret  Data 

A4.4  Produce 

Surveillance  Product 

1.  Perform  Ground  Control  Functions 

1.1.  Perform  Operator  Functions 

l.l.l.Provide  UAV  Control  Inputs 

x 

x 

X 

x 

x 

1.1.2.Provide  Sensor  Control  Inputs 

X 

X 

x 

x 

1.1.3. Provide  Mission  Planning  Inputs 

X 

X 

X 

X 

1.1.4.Monitor  Mission  Execution 

x 

X 

1.1.5. Manipulate  Surveillance  Product 

x 

X 

1.1.6.lnterface  with  C2ISR 

X 

X 

X 

x 

X 

1.2.  Perform  Ground  Transceiver 

Functions 

1.2.1. Modulate  Communications  Data 

for  UAVs 

x 

x 

X 

X 

X 

x 

1.2.2. Demodulate  Communications 

Data  from  UAVs 

X 

X 

X 

X 

X 

x 

1.2.3. Demodulate  Sensor  Data  from 

UAVs 

X 

x 

1.2,4.Transmitand  Receive 

Modulated  Ground  Data 

X 

X 

X 

X 

X 

X 

X 

X 

X 

1.3.  Perform  CUSS  Software  Functions 

1.3.1.Provide  Operator  Interface 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

1.3.2.lnterface  with  Ground 

Transceiver 

X 

X 

X 

X 

X 

X 

X 

X 

X 

1.3.3. Provide  Electronic  C2ISR 

Interface 

X 

X 

X 

X 

X 

1.3.4.Capture  Surveillance  Data 

X 

X 

1.3.5.Generate  Surveillance  Product 

1.3.6.Compute  Mission  Plan 

x 

1.3.7.Track  Mission  Status 

X 

x 

X 

X 

X 

X 

1.3.8.Compute  UAV  Control 
Commands 

X 

X 

X 

1.3.9.Compute  Sensor  Control 
Command 

X 

X 

X 

1.3.10.Accept  GPS  Receiver  Signal 

X 

X 

2.  Perform  Airborne  Control  Functions 

2.1.  Perform  Airborne  Control  Unit 

Functions 

2.1.1.lnterface  with  Airborne 

Transceiver 

X 

X 

X 

X 

X 

X 

X 

X 

X 

2.1.2.Receive  Aircraft  Status  Data 

X 

X 

X 

X 

X 

X 

2.1.3.Receive  Sensor  Status  Data 

X 

X 

X 

2.1.4.Produce  Flight  Control 
Commands 

X 

2.1.5.Produce  Sensor  Control 

Commands 

X 

2.1.6.Compute  Navigation  Solution 

X 

2.1.7.Compute  Sensor  Solution 

X 

2.2.  Perform  Airborne  Transceiver 

2.2.1. Demodulate  Communications 

X 

X 

X 

X 

X 

X 

2. 2.2. Demodulate  Reference  Signal 

X 

2.2.3. Modulate  Communications  Data 

X 

X 

X 

X 

X 

X 

2.2.4.Modulate  Sensor  Data  for  GCU 

X 

X 

2.2.5.Transmitand  Receive 

Modulated  Airborne  Data 

X 

X 

X 

X 

X 

X 

X 

X 

X 

By  comparing  and  evaluating  each  system  function  against  the  operational 
activities,  the  team  showed  that  each  operational  activity  was  realized  through  system 
functions  and  each  system  function  supported  one  or  more  operational  activities. 
Evaluation  of  this  matrix  allowed  the  team  to  determine  if  any  system  components  were 
being  underutilized  or  overburdened  during  operational  use.  The  Provide  Operator 
Interface  function  performed  by  the  CUSS  Software  is  involved  in  every  operational 
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activity.  Also,  the  Ground  and  Airborne  Transceivers  are  key  to  activities  that  involve 
communications  between  the  Ground  and  Airborne  System  Nodes.  Sufficient  processing 
power  and  software  stability  will  minimize  the  possibility  of  the  interface  being  a  system 
limitation.  The  transceivers  must  be  designed  with  enough  capacity  to  handle  the  amount 
of  communications  identified,  as  well  as  reliability  and  redundancy.  Overall,  the  team 
believes  system  utilization  across  the  architecture  is  balanced  and  appropriate  for  the 
required  functions  performed  by  the  CUSS.  Furthermore,  the  SV-5  shows  that  the 
envisioned  physical  implementation  is  feasible  for  achieving  the  necessary  operational 
activities. 

Test  Architecture 

Upon  completing  the  conceptual  architecture  and  reviewing  the  actual  flight  test 
configuration,  the  team  created  a  test  architecture  that  accurately  depicts  the  components 
and  functionality  of  the  prototype  system.  The  test  architecture  products  include  a 
modified  OV-1,  OV-2,  OV-5,  and  SV-1.  The  SV-4  and  SV-5  remain  unchanged  from  the 
conceptual  architecture. 

OV-1. 

The  high  level  operation  concept  shown  in  Figure  32  depicts  the  operational 
scenario  the  team  used  to  validate  the  conceptual  architecture  and  demonstrate  the 
feasibility  of  cooperative  control  with  multiple  UAVs.  Within  this  scenario,  the  Operator 
was  tasked  to  provide  persistent  surveillance  of  stationary  vehicles  using  four  BATCAM 
UAVs.  Once  the  UAVs  were  airborne,  the  Operator  provided  command  and  control 
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inputs  to  the  Kestrel™  Autopilot  resident  on  each  BATCAM  using  the  Laptop  interface, 
Virtual  Cockpit™  software,  and  the  Commbox  from  inside  the  Flight  Test  Trailer.  The 
Kestrel™  autopilot  also  used  this  same  communications  path  to  return  Telemetry  Data  to 
the  Operator.  Sensor  Feed  information  was  returned  via  a  2.4-2. 5  GHz  analog  video  link 
and  displayed  to  the  Operator  on  the  Laptop  screen  in  a  Quad  Video  format. 


Virtual  Cockpit™ 


Quad  Video 


OV-1:  Test  System  Concept 

GPS 

v 


GPS  Signal""  Commbox 
Comm  Link  (900  MHz) 

Video  Data  (2.4  GHz) 


FlightTest  Tiailei 


Kestrel™  Autopilot 


A 

BATCAM 


Figure  32.  Test  OV-1  System  Concept 


The  OV-1  highlights  some  notable  differences  between  the  conceptual  system  and 
the  test  system.  First,  there  are  no  communication  links  between  the  aircraft;  they  only 
communicate  with  the  ground  station.  This  means  that  the  aircraft  do  not  share  data 
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directly  or  relay  data  from  the  ground  station  to  each  other.  Also,  there  is  no  link  to  any 
external  C2ISR  entity. 

OV-2. 

The  test  OV-2,  shown  in  Appendix  L,  shows  minor  differences  from  the 
Conceptual  OV-2.  The  C2ISR  Node,  which  would  represent  higher  command  in 
battlefield  operations,  is  simulated  by  the  test  team.  The  Reference  Node  and  Reference 
Node  Signal  is  not  depicted,  since  the  aircraft  were  not  equipped  to  receive  a  beacon 
signal.  The  Virtual  Cockpit™  software  does  include  the  ability  to  direct  aircraft  based  on 
the  position  of  the  ground  station,  in  effect  acting  as  a  reference  signal,  but  this  capability 
was  not  implemented  in  any  tests.  Lastly,  the  UA  V  Airframe  Node  did  not  collect 
Weather  Data  or  generate  Weather  Alerts,  so  the  team  eliminated  Measured  Weather 
Data  and  Measured  Weather  Alerts  from  the  diagram. 

OV-5. 

The  test  OV-5,  shown  in  Appendix  M,  also  contains  minor  differences  from  the 
Conceptual  OV-5.  All  operational  activities  were  present  in  the  test  system,  but  most 
were  not  as  robust  as  envisioned. 

In  the  External  Systems  Diagram,  Figure  33,  as  in  the  OV-2,  the  Provide  C2ISR 
operational  activity  is  simulated  by  the  test  team,  the  Provide  Reference  Location  activity 
and  all  ICOMs  going  in  and  out  of  the  activity  are  deleted,  and  the  Measured  Weather 
Alert  and  Measured  Weather  Data  ICOMs  are  also  omitted. 
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A-0  Provide  Surveillance  External  Systems  Diagram  (Test)  (OV-05  Activity  Model) 
System  Architect 
Mon  Feb  02,  2009  14:27 


Figure  33.  Test  OV-5  A-0  External  Systems  Diagram 

These  changes  flow  to  the  Context  Diagram  and  the  AO  Provide  Surveillance 
Diagram,  Figure  69  and  Figure  70  in  Appendix  M.  Internal  to  the  AO  Provide 
Surveillance  Diagram,  the  team  deleted  the  Sensor  Tracking  Error  ICOM  which  leaves 
the  A3  Control  Sensors  operational  activity  and  enters  the  A2  Manage  UA  Vs  operational 
activity;  the  UA  V  Orientation  and  UA  V Position  and  Velocity  ICOMs  which  enter  the  A3 
Control  Sensors  operational  activity;  and  the  Target  Location  ICOM  exiting  the  A4 
Manage  Surveillance  Data  operational  activity  and  entering  the  A I  Plan  Mission  and  A2 
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Manage  UA  Vs  operational  activities.  The  test  system  could  not  automatically  track  a 
target  with  its  sensors  or  generate  target  location  data  from  its  sensors. 

All  of  these  changes  flow  to  the  AO  level  diagrams.  There  are  no  changes  internal 
to  any  of  the  A1  level  child  diagrams,  as  all  functionality  of  these  diagrams  is  realized  by 
the  test-bed  system. 

SV-1. 

The  most  significant  differences  between  the  conceptual  and  test  architectures  can 
be  discerned  from  the  two  versions  of  the  SV-1.  The  conceptual  SV-1,  shown  in 
Appendix  H,  shows  a  more  abstract  view  of  the  system,  providing  a  general  description 
of  system  components  that  need  to  be  implemented.  The  test  SV-1,  shown  in  Figure  34, 
shows  the  specific  components  used  in  the  test  bed  system.  Ideally,  if  the  conceptual 
system  was  implemented,  the  components  in  the  test  bed  system  would  be  combined  and 
integrated  into  the  components  identified  in  the  conceptual  architecture. 
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CUSS  (Test)  (SV-01  Systems  Interface) 
System  Architect 
Mon  Feb  02, ,2009  15:57 


Figure  34.  Test  SV-1  System  Interface  Description 


To  show  the  correlation  between  the  two  diagrams,  the  team  developed  a 
component  mapping  matrix,  shown  in  Table  2  that  shows  which  actual  test  components 
were  used  to  accomplish  the  functions  of  the  conceptual  system  components. 
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Table  2.  Test  to  Conceptual  Component  Mapping  Matrix 


Conceptual  CUSS  System  Components 


Ground  System 

Airborne  System 

Test  System  to  Conceptual 

System  Component  Mapping 

Operator 

Computing  Device 

CUSS  Software 

Ground  Transceiver 

GPS  Receiver 

Communications 

Antenna  (Ground 

Air  Vehicle 

Airborne  Control  Unit 

Sensor  Package 

Airborne  Transceiver 

Communications 

Antenna  (Airborne 

Test  System 
Components 

Operator 

X 

La  ptop 

X 

Monitor 

X 

Manual  R/C  Controller 

X 

VC  Softwa  re 

X 

C++  Interface 

X 

Matlab  Algorithm 

X 

4-Way  Switcher 

X 

DVR 

X 

Maxstream  Modem  in  Commbox 

X 

Power  Divider  (2) 

X 

Video  RX  (8) 

X 

Oracle  Dual  Diversity  (4) 

X 

AverMedia  Video  Capture 

Device 

X 

GPS  Antenna 

X 

GPS  Receiver 

X 

Video  Antenna  (2) 

X 

Communications  Antenna 
(Ground  System) 

X 

Airborne 

System 

BATCAM  Ai  rfra  me 

X 

Furuno  GPS  RX 

X 

Kestrel  Autopilot 

X 

Front  Camera 

X 

Side  Camera 

X 

Camera  Controller  Board 

X 

Maxstream  Modem  (Airborne 
System) 

X 

Communications  Antenna 
(Airborne  System) 

X 

Video  Antenna 

X 

Based  on  this  component  mapping,  the  team  decided  that  the  test  system 
components  effectively  produced  the  functions  of  the  conceptual  system  components. 
Therefore,  the  SV-4  System  Functionality  Description  and  SV-5  Operational  Activity  to 
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System  Function  Traceability  Matrix  for  the  conceptual  architecture  applied  to  the  test 
architecture  as  well. 

Flight  Testing 

Autopilot  Tuning. 

Tuning  Flights. 

The  first  step  in  making  the  test  system  viable  for  performing  algorithm  testing 
was  to  tune  the  Kestrel™  autopilot  to  the  BATCAM  airframe.  Within  its  nonvolatile 
memory,  the  autopilot  houses  a  set  of  Proportional/Integral/Derivative  (PID)  feedback 
gains  and  a  set  of  miscellaneous  parameters  known  as  Flash  values.  The  PID  values 
govern  the  behavior  of  the  autopilot  control  loops,  while  the  Flash  values  specify  a  large 
variety  of  settings  such  as  servo  limits,  modem  settings,  waypoint  tracking  parameters, 
loiter  orbit  direction,  and  trim  pitch  and  airspeed  values.  The  team  started  with  a  baseline 
set  of  PID  and  Flash  values  generated  from  BATCAM  preloaded  software  and 
recommended  defaults  from  Procerus.  For  tuning,  the  team  used  published  procedures 
from  Procerus  to  tune  the  control  loops  and  adjust  the  other  flight  parameters. 

Contrary  to  team  expectations,  the  tuning  process  took  two  and  one  half  days  of 
testing  and  forty-three  flights  to  satisfactorily  tune  all  four  aircraft.  A  number  of  issues 
contributed  to  the  length  of  this  process.  First,  it  took  several  attempted  launches  to 
discover  that  the  V-tail  control  surfaces  moved  the  aircraft  in  an  unexpected  manner. 
Instead  of  controlling  the  aircraft  like  ailerons  to  produce  roll,  V-tail  surfaces  act  to  yaw 
the  aircraft.  This  yawing  motion  induces  a  roll  in  the  direction  of  the  yaw. 
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Next,  the  team  discovered  that  the  aircraft  was  nearly  uncontrollable  in  the  yaw 
and  roll  axes  when  flown  manually  by  the  RC  operator  due  to  aircraft  instability. 
Although  the  tuning  procedures  specified  to  start  with  all  autopilot  control  loops  disabled, 
after  several  short  attempts  at  stable  flight,  the  team  decided  to  enable  the  rate  loops.  The 
yaw,  roll,  and  pitch  rate  loops  produce  control  commands  to  counter  sensed  rates  around 
the  corresponding  axes.  The  preloaded  BATCAM  PID  values  for  these  loops  were 
sufficient  to  fly  the  aircraft  manually  with  rate  loop  assistance. 

Many  of  the  remaining  default  PID  values,  however,  were  not  adequate  to  allow 
the  aircraft  to  achieve  and  maintain  the  desired  altitude.  The  majority  of  the  remaining 
tuning  tests  were  spent  refining  pitch  and  throttle  control  loops  to  tighten  altitude  control. 
This  process  was  exacerbated  by  the  BATCAM’ s  susceptibility  to  winds,  which  was  due 
to  its  small  size,  and  its  relatively  short  flight  times,  which  were  typically  between  1 5  and 
20  minutes. 

System  Impact. 

This  tuning  process  is  not  trivial  to  the  implementation  of  a  common  control 
system  for  use  in  multiple  types  of  UAVs.  Before  a  system  like  the  CUSS  can  be 
installed  on  a  particular  airframe,  it  must  be  thoroughly  tuned  to  properly  control  that 
platform.  Ideally,  this  should  be  performed  by  a  testing  team  responsible  for  integration 
efforts.  Then  those  settings  should  be  fixed  to  a  standard,  distributed  to  UAVs  in  the 
field,  and  updated  through  a  formal  process  as  required.  Manpower,  facility,  airspace, 
and  cost  requirements  will  be  impacted  by  this  process. 

With  a  common  platform,  the  majority  of  the  tuning  parameters  can  be 
standardized  across  each  aircraft.  However,  the  team  found  that  individual  BATCAMs 
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required  control  surface  trim  and  autopilot  sensor  calibration  settings  that  were  specific  to 
each  individual  aircraft.  Consequently,  this  issue  will  likely  become  a  future  field 
maintenance  requirement  for  operational  users.  After  setting  these  values  for  each  UAV, 
operators  will  also  need  to  periodically  update  them  as  sensors  drift  and  aircraft 
aerodynamics  change  from  normal  wear  and  tear  during  operational  use. 

BA  TCAM  Performance. 

The  team  used  the  flight  tests  to  measure  the  performance  of  the  BATCAM 
UAVs,  focusing  on  parameters  that  affect  mission  planning,  formation  management,  and 
sensor  placement.  Data  was  captured  from  personal  observations  as  well  as  the  data 
logger  built  into  Virtual  Cockpit™,  which  stores  telemetry  in  MATLAB®  files. 

Airspeed. 

The  aircraft  was  trimmed  at  half  throttle,  which  produced  a  trim  airspeed  of  20 
knots  (kts).  This  was  used  as  a  baseline  for  all  flight  plans.  The  maximum  and  stall 
speeds  were  not  specifically  tested;  however,  the  maximum  recorded  speed  after  autopilot 
tuning  was  44  kts  in  a  dive  and  the  minimum  recorded  was  5  kts  during  a  landing 
approach. 

Endurance. 

Flight  time  was  limited  by  the  battery  and  affected  by  several  factors  such  as 
temperature,  average  airspeed,  and  altitude  changes.  Nearly  all  tests  were  conducted  with 
a  1320  milliampere-hour  (mAh)  Lithium  Polymer  (LiPo)  battery.  The  length  of  a  ground 
test  run  at  full  motor  power  was  1 1  minutes  (min).  The  typical  duration  of  flight  test 
sorties  terminated  due  to  low  battery  voltage  was  around  20  min.  The  longest  sortie  with 
this  battery  was  measured  at  28  min. 
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The  BATCAM  kits  also  came  with  several  larger  2100  mAh  LiPo  batteries.  The 
team  test  flew  these  batteries  and  confirmed  the  same  trim  values  and  PID  settings  could 
be  used  for  both  sizes  of  batteries.  The  team  also  performed  an  endurance  test  flight  with 
a  2100  mAh  battery.  The  flight  length  was  44  min,  a  57%  improvement  over  the  longest 
small  battery  flight,  and  in  accordance  with  the  59%  increase  in  available  energy 
capacity. 

Turn  Time. 

Although  the  minimum  time  required  between  sorties,  “turn  time,”  is  a  function 
of  the  aircraft,  it  is  also  dependent  on  the  control  system.  Maintenance  on  the  BATCAM 
between  sorties  was  minimal,  consisting  only  of  changing  the  battery  and  inspecting  the 
exterior  for  damage.  The  control  system  required  time  to  reacquire  a  GPS  lock  and  fix 
the  aircraft’s  position.  The  operator  had  to  zero  the  static  pressure  reading,  which 
changed  from  flight  to  flight,  and  perform  a  check  of  the  pitot  system  to  ensure  proper 
airspeed  and  altitude  readings.  The  operator  also  had  to  upload  the  flight  plan  to  the 
autopilot  through  Virtual  Cockpit™. 

The  team  conducted  a  turn  time  test  in  conjunction  with  a  persistent  surveillance 
scenario  on  9  Feb  2009.  The  objective  of  the  test  was  to  establish  and  maintain  two 
aircraft  on  station  over  a  target  while  conducting  five  total  flights.  Three  aircraft  were 
used  in  the  test,  requiring  two  aircraft  turns.  The  aircraft  were  launched  every  five 
minutes.  Once  the  third  aircraft  had  been  launched  and  established  on  station,  the  first 
was  recovered  and  turned.  The  same  recovery  and  turn  took  place  for  the  second  aircraft 
launched.  A  timeline  of  the  test  is  shown  in  Figure  35. 
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16:29 

BATCAM  2  Land 


16:33 

BATCAM  3  Land 


16:47 

BATCAM  2  Land 


Figure  35.  Persistent  Surveillance  and  Turn  Test  Timeline 


The  aircraft  turns  were  measured  from  the  time  the  aircraft  touched  the  ground  on 
landing  until  the  aircraft  was  ready  to  be  placed  into  takeoff  mode  for  launch  again.  The 
first  turn  was  measured  at  1  min  43  seconds  (s),  and  the  second  at  1  min  20  s.  The 
aircraft  were  ready  to  re-launch  at  the  five  minute  interval.  This  procedure  could  have 
been  performed  continuously,  resulting  in  an  indefinite  persistent  surveillance  of  the 
target. 

Altitude. 

The  ability  of  the  aircraft  to  hold  the  desired  altitude  was  measured  by  comparing 
the  measured  altitude  to  the  commanded  altitude  in  the  telemetry  data.  This  comparison 
was  only  made  after  the  aircraft  had  reached  the  commanded  altitude,  and  for  as  long  as 
the  commanded  altitude  remained  constant.  This  eliminated  errors  while  the  aircraft  was 
in  transition.  It  is  important  to  note  that  this  characterization  does  not  account  for  errors 
in  the  aircraft’s  altitude  sensing  system,  which  is  based  on  static  pressure.  It  is  in  essence 
a  performance  measurement  of  the  altitude  control  loops  in  the  autopilot. 
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Figure  36  shows  an  example  commanded  and  measured  altitude  profile  during 
one  of  the  test  flights.  The  bands  at  the  bottom  of  the  figure  represent  the  areas  where  the 
data  points  met  the  above  criteria  for  inclusion  in  the  performance  measurement. 
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Figure  36.  Example  Altitude  Profile 

This  analysis  was  performed  on  a  test  flight  in  which  all  four  BATCAMs  were 
flown.  All  vehicles  had  the  exact  same  PID  values  for  all  control  loops;  the  only 
differences  in  settings  were  aircraft  servo  trim  and  sensor  calibration  values.  Figure  37 
shows  the  altitude  profiles  for  the  four  aircraft  over  the  course  of  the  test  on  13  Nov  2008. 
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Figure  37.  4-Ship  Altitude  Profile 


Figure  38  shows  the  deviations  between  the  measured  and  commanded  altitudes 
for  the  observed  segments  of  the  above  profiles.  A  positive  deviation  means  that  the 
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Figure  38.  Altitude  Deviations 
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aircraft  was  above  the  commanded  altitude,  and  vice-versa.  The  largest  deviations 
generally  occurred  at  the  end  of  the  sortie,  as  the  aircraft  transitioned  to  their  pre-landing 
orbits. 

Table  3  lists  the  maximum  high  and  low,  mean,  and  root  mean  square  (RMS) 
deviations  for  each  aircraft  and  all  test  points  combined.  The  RMS  deviation  is  a 
measurement  of  how  far  off  assigned  altitude  (high  or  low)  the  aircraft  was  on  average. 
The  bias  towards  low  altitude  shown  in  Table  3  suggests  that  the  trim  angle-of-attack  was 
set  too  low. 


Table  3.  Altitude  Deviation  Statistics 


Aircraft 

Max  High 

(ft) 

Max  Low 

(ft) 

Mean  (ft) 

RMS  (ft) 

1 

26.2 

-45.4 

-3.1 

11.1 

2 

21.3 

-38.3 

-5.5 

11.5 

3 

28.4 

-49.2 

-8.7 

14.4 

4 

30.1 

-47.0 

-2.0 

14.0 

All 

30.1 

-49.2 

-4.9 

12.8 

Figure  39  is  a  histogram  of  altitude  deviations  at  each  of  the  measurement  points 
for  all  four  aircraft,  divided  into  50  bins.  The  data  appears  to  be  normally  distributed.  A 
best  fit  normal  distribution  was  generated  using  parameters  from  the  MATLAB® 
“normfit”  function.  “Normfit”  provides  estimates  of  the  mean  ( jli  )  and  standard  deviation 
(a)  for  the  given  data.  The  probability  density  function  for  a  normal  distribution  is 
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defined  in  Equation  1 .  The  best  fit  normal  distribution  is  overlaid  on  the  histogram  data 
in  Figure  39  with  vertical  lines  noting  p,  p±o,  and  g±2c. 

y  =  f(x\ii.a)=7^eJ^  (0 


Figure  39.  Altitude  Deviation  Histogram 


Figure  40  shows  a  cumulative  distribution  function  (CDF)  for  the  altitude 
deviation  data  overlaid  on  the  best  fit  normal  distribution  CDF.  The  close  fit  is  further 
evidence  of  a  normal  distribution.  If  this  assumption  is  valid,  the  aircraft  can  be  expected 
to  remain  within  +19  to  -29  ft  of  assigned  altitude  95%  of  the  time  (within  2a). 
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Altitude  Deviation  (ft) 


Figure  40.  Altitude  Deviation  Cumulative  Distribution  Function 


Waypoint  Navigation. 

BATCAM  navigation  performance  was  measured  in  much  the  same  manner  as 
altitude  performance.  For  navigation  between  waypoints  the  aircraft  position  was 
compared  to  a  straight  line  course  between  the  two  navigation  points.  The  measurements 
were  taken  when  the  aircraft  was  in  waypoint  navigation  mode  and  was  established  on 
the  navigation  leg.  Again,  this  does  not  account  for  errors  in  the  sensed  position  of  the 
aircraft  from  the  GPS;  it  only  measures  autopilot  control  loop  performance. 

Figure  41  shows  an  example  of  aircraft  position  and  the  commanded  waypoints 
during  the  flight.  The  set  of  waypoints  that  forms  the  hexagonal  shape  (1-6)  were  where 
the  aircraft  was  in  waypoint  navigation  mode.  This  is  opposed  to  waypoints  such  as  the 
“Rally”  point  which  commanded  a  loiter  orbit. 
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Figure  41.  Example  Navigation  Ground  Track  and  Waypoints 


The  analysis  was  performed  on  the  same  test  flight  as  the  altitude 
characterization,  where  all  four  aircraft  were  flown.  The  winds  during  this  flight  test 
were  from  the  south  at  10  to  12  kts.  The  winds  caused  the  aircraft  to  be  blown  off  course 
to  the  north,  as  seen  in  Figure  41 .  Deviation  was  defined  as  the  perpendicular  distance 
between  the  line  between  the  two  waypoints  and  the  aircraft’s  position,  where  positive 
refers  to  the  aircraft  being  right  of  course.  This  is  shown  in  Figure  42  which  depicts  a 
negative  deviation. 
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Deviation  (m) 


Figure  42.  Course  Deviation  Definition 

The  course  deviations  for  all  four  aircraft  are  shown  in  Figure  43.  The  largest 
deviations  typically  occurred  when  the  aircraft  were  turning  on  the  two  legs  from 
downwind  to  upwind  (between  waypoints  4,  5,  and  6  in  Figure  41). 
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Figure  43.  Course  Deviations 
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Table  4  lists  the  maximum  right  (positive)  and  left  (negative),  mean,  and  RMS 


deviations  for  each  aircraft  and  all  test  points  combined.  The  bias  towards  left  of  course 
shown  in  Table  4  is  due  to  a  combination  of  the  winds  with  the  clockwise  direction  of  the 
series  of  waypoints. 


Table  4.  Course  Deviation  Statistics 


Aircraft 

Max  Right 
(m) 

Max  Left 
(m) 

Mean  (m) 

RMS  (m) 

1 

31.3 

-54.1 

-6.4 

16.9 

2 

39.4 

-34.5 

-0.6 

16.7 

3 

36.1 

-35.1 

-3.9 

14.7 

4 

34.9 

-42.3 

-5.4 

16.7 

All 

39.4 

-54.1 

-4.1 

16.3 

Figure  44  is  a  histogram  of  course  deviation  at  each  of  the  measurement  points  for 
all  four  aircraft,  divided  into  50  bins.  Again,  the  data  appears  to  be  normally  distributed. 
A  best  fit  normal  distribution  is  overlaid  on  the  data  in  Figure  44  with  vertical  lines 
noting  p,  |i±o,  and  p±2o. 
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Course  Deviation  (m) 


Figure  44.  Course  Deviation  Histogram 


Figure  45  shows  the  altitude  deviation  data  CDF  overlaid  on  the  best  fit  normal 
distribution  CDF.  Again,  the  close  fit  is  further  evidence  of  a  normal  distribution.  If  this 


Figure  45.  Course  Deviation  Cumulative  Distribution  Function 
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assumption  is  valid,  the  aircraft  can  be  expected  to  remain  within  +27  to  -36  m  of 
assigned  course  95%  of  the  time  (within  2a).  The  numbers  are  only  valid  in  similar  wind 
conditions  with  the  aircraft  flying  right-hand  turns. 

Loiter. 

The  other  type  of  waypoint  navigation  for  the  Kestrel™  autopilot  is  a  loiter  mode 
where  the  aircraft  orbits  the  selected  waypoint  at  a  specified  radius.  To  measure 
performance  in  loiter  mode,  the  aircraft  radial  distance  from  the  waypoint  was  compared 
to  the  specified  orbit  radius.  The  measurements  were  taken  from  when  the  aircraft  was 
commanded  to  loiter  mode  and  had  closed  to  the  desired  orbit  radius  until  another  mode 
was  selected.  Once  again,  these  measurements  do  not  take  GPS  errors  into  account.  The 
circular  path  around  waypoint  1  shown  in  Figure  46  is  an  example  of  an  aircraft  orbit 
track. 


Figure  46.  Example  Orbit  Ground  Track  and  Waypoints 
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The  analysis  was  performed  on  a  flight  test  on  9  Feb  2009  in  which  all  four 
aircraft  were  flown  primarily  in  counter-clockwise  loiter  orbits.  The  specified  orbit 
radius  was  75  m.  The  winds  on  this  test  were  out  of  the  southeast  varying  from  7  to  14 
kts.  The  aircraft  were  blown  to  the  northwest  of  the  orbit  point,  as  seen  in  Figure  46. 
Orbit  deviations  were  defined  as  the  difference  between  the  aircraft  distance  from  the 
waypoint  and  the  commanded  orbit  radius,  where  positive  refers  to  the  aircraft  being 
outside  the  desired  radius.  This  is  shown  in  Figure  47  which  depicts  a  positive  deviation. 


Figure  47.  Orbit  Deviation  Definition 

The  orbit  deviations  for  all  four  aircraft  are  shown  in  Figure  48.  The  greatest 
deviations  occurred  when  the  aircraft  were  turning  from  downwind  to  upwind,  similar  to 
the  results  of  the  course  deviation  test. 
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Figure  48.  Orbit  Deviations 


Table  5  lists  the  maximum  outside  (positive)  and  inside  (negative),  mean,  and 
RMS  deviations  for  each  aircraft  and  all  test  points  combined.  The  system  is  biased 
towards  flying  outside  the  orbit. 


Table  5.  Orbit  Deviation  Statistics 


Aircraft 

Max 

Outside  (m) 

Max  Inside 
(m) 

Mean  (m) 

RMS  (m) 

1 

97.8 

-61.4 

8.7 

31.9 

2 

71.9 

-60.7 

12.0 

23.1 

3 

89.9 

-72.1 

6.3 

28.4 

4 

85.0 

-39.0 

18.6 

29.6 

All 

97.8 

-72.1 

10.7 

29.0 
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Figure  49  shows  a  histogram  of  orbit  deviation  data  from  all  four  aircraft,  split 
into  50  bins.  Because  there  is  a  limit  to  the  deviation  inside  the  orbit  (the  commanded 


orbit  radius,  or  -75  m),  a  normal  distribution  would  not  fit  the  data.  A  best  fit  gamma 
distribution  was  generated  using  parameters  from  the  MATLAB®  “gamfit”  function. 
“Gamfit”  provides  estimates  of  the  gamma  distribution  parameters  “a”  and  “b”  for  the 
given  data.  The  probability  density  function  for  a  Gamma  Distribution  is  defined  in 
Equation  2  where  Y  is  the  Gamma  function.  Figure  49  shows  a  best  fit  gamma 
distribution  overlaid  on  the  histogram  as  well  as  the  distribution  mean  (jli). 

y  =  f(x\a,b)  =-^-)xa~1eb  (2) 


Obit  Deviation  (m) 


Figure  49.  Orbit  Deviation  Histogram 
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Figure  50  shows  the  orbit  deviation  data  CDF  overlaid  on  the  best  fit  gamma 
distribution  CDF.  If  the  distribution  is  valid,  the  aircraft  can  be  expected  to  fly  no  more 
than  62  m  outside  the  orbit  radius  95%  of  the  time.  This  is  only  valid  in  similar  wind 
conditions  and  for  a  75  m  orbit  radius. 


Obit  Deviation  (m) 


Figure  50.  Orbit  Deviation  Cumulative  Distribution  Function 

This  result  is  considerably  large  and  differs  significantly  from  the  aircraft 
performance  in  waypoint  navigation.  The  tests  were  performed  on  different  dates  with 
different  wind  conditions.  More  significantly,  the  autopilot  uses  different  control  loops 
for  waypoint  and  loiter  navigation.  It  is  possible  to  adjust  the  loiter  navigation  flash 
parameters  without  affecting  waypoint  navigation.  Though  loiter  navigation  values  were 
adjusted  during  the  autopilot  tuning  process,  further  experimentation  with  these 
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parameters  may  yield  better  results.  This  result  does  demonstrate  the  BATCAM’s 
susceptibility  to  even  light  wind  conditions,  i.e.,  less  than  15  kts. 

System  Impact. 

The  types  of  parameters  examined  above  and  the  methods  used  to  characterize 
them  are  important  in  implementing  a  common  cooperative  control  system.  For  example, 
airspeed  limitations  affect  to  what  degree  airspeed  commands  can  be  used  to  adjust  the 
formation  position  of  a  UAV,  or  whether  it  can  keep  up  with  a  moving  target.  It  also 
drives  timing  calculations  during  mission  planning.  Aircraft  endurance  affects  mission 
planning  calculations  of  mission  range  and  on-station  time.  This,  in  turn,  dictates  the 
number  of  aircraft  and  sorties  required  to  accomplish  a  mission.  Aircraft  turn  time 
affects  the  ability  to  achieve  persistent  surveillance  by  generating  a  continuous  stream  of 
sorties.  Altitude  and  navigation  deviations  impact  formation  considerations  such  as  safe 
separation  for  deconfliction  purposes.  Altitude  performance  can  also  impact  whether  a 
system  is  allowed  to  fly  in  civilian  airspace  based  on  maintaining  regulated  tolerances. 
Navigation  performance  is  also  important  in  ensuring  UAV  sensors  can  be  successfully 
placed  on  target,  particularly  in  the  case  of  fixed  sensors. 

If  the  system  is  to  be  scalable  to  a  number  of  different  UAV  airframes,  each 
aircraft  type  will  need  to  be  characterized  and  its  parameters  captured  in  a  dataset. 
Mission  planning,  formation  management,  and  navigation  algorithms  will  need  to  utilize 
those  parameter  datasets  in  their  calculations,  potentially  multiple  sets  if  multiple  aircraft 
types  are  used  simultaneously. 
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Communications  Performance. 

The  team  was  able  to  measure  one  aspect  of  communications  performance  during 
the  flight  tests.  The  data  logger  in  Virtual  Cockpit™  captures  telemetry  packets 
generated  by  the  Kestrel™  autopilots.  The  telemetry  packets  include  a  time  stamp  in 
milliseconds  (ms),  which  allowed  the  team  to  measure  the  rate  of  packets. 

Multiple  Aircraft. 

The  default  setting  on  the  Kestrel™  autopilot  broadcasts  telemetry  packets 
continuously  with  no  deconfliction.  When  the  team  initially  attempted  to  run  multiple 
autopilots  simultaneously,  a  significant  drop  in  packet  rate  was  observed  for  each  agent 
added.  Additionally,  within  Virtual  Cockpit™  is  a  warning  and  failsafe  setting  that 
triggers  the  aircraft  to  return  to  the  Rally  point  if  no  telemetry  is  received  within  a  user 
defined  period  of  time  (6  seconds  for  the  test  flights  conducted).  This  warning  and 
failsafe  triggered  several  times  in  ground  testing  with  three  or  more  aircraft,  and  once 
during  a  flight  with  just  two  aircraft.  This  drop  in  communications  performance  was  due 
to  the  fact  that  the  telemetry  transmissions  were  not  deconflicted.  If  a  packet  arrived  at 
the  Commbox  while  another  was  being  received,  then  a  packet  collision  occurred  and 
both  sets  of  data  were  lost. 

To  mitigate  this  problem,  the  team  switched  the  communications  scheme  in 
Virtual  Cockpit™  and  on  the  Kestrel™  autopilot  to  a  polling  structure.  This  caused  the 
autopilot  to  only  transmit  a  telemetry  packet  when  polled  by  the  ground  station.  The 
ground  station,  in  turn,  polled  the  agents  in  sequence.  It  maintained  a  minimum  time  of 
100  milliseconds  (ms)  between  each  poll  and  waited  a  maximum  of  300  ms  for  a  reply 
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before  polling  the  next  agent.  If  a  telemetry  packet  was  received  after  the  300  ms  wait 
time,  the  receiver  was  still  able  to  process  it  as  long  as  a  packet  collision  did  not  occur. 

This  packet  polling  scheme  resulted  in  overall  slower  telemetry  rates  than  non¬ 
polling,  but  had  the  advantage  of  reduced  packet  collisions.  Table  6  shows  a  comparison 
of  polling  and  non-polling  telemetry  data  rates  in  packets  per  second  (PPS)  and  the 
maximum  observed  time  between  packets  received  for  a  ground  test  with  four  aircraft. 
Though  packet  collisions  do  not  appear  to  occur  often  in  non-polling,  when  several  do 
occur,  the  result  can  be  the  activation  of  the  loss-of-communication  failsafe.  For  the 
team,  this  reduced  risk  afforded  by  the  polling  structure  outweighed  the  faster  telemetry 
rates. 


Table  6.  Polling  and  Non-Polling  Telemetry  Comparison 


Aircraft 

Non-Polling 
Data  Rate 
(PPS) 

Polling  Data 
Rate  (PPS) 

Non-Polling 
Max  Packet 
Delay  (s) 

Polling  Max 
Packet  Delay 
(s) 

1 

1.6 

1.1 

4.9 

3.9 

2 

1.3 

1.0 

4.1 

3.9 

3 

1.6 

1.1 

3.1 

3.5 

4 

1.6 

1.0 

3.1 

3.3 

All 

1.5 

1.0 

4.9 

3.9 

High  Ground  Control  Command  Rates. 

The  team  observed  a  related  communications  problem  when  testing  Capt  Booth’s 
cooperative  control  algorithm  [34],  His  program  generated  flight  paths  of  equal  lengths 
for  multiple  aircraft  to  fly  with  the  goal  of  having  them  arrive  in  an  orbit  simultaneously. 
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To  further  refine  arrival  times  and  then  keep  the  UAVs  equidistant  within  the  orbit,  his 
algorithm  generated  airspeed  commands  for  each  aircraft.  These  commands  were 
initially  sent  at  a  rate  of  one  per  second  for  each  aircraft. 

In  flight  testing,  as  soon  as  the  algorithm  started  sending  these  commands  to  the 
aircraft,  the  team  observed  a  noticeable  drop  in  telemetry  rate.  Also,  part  of  the  flight  test 
procedures  had  the  operator  request  each  aircraft  to  download  its  waypoints  to  Virtual 
Cockpit™.  This  process  was  noticeably  slower  with  the  algorithm  operating.  Both 
effects  were  exaggerated  when  the  team  changed  from  testing  the  algorithm  with  two 
aircraft  to  three.  Between  flight  tests  of  three  aircraft,  Capt  Booth  changed  the  algorithm 
to  command  airspeeds  every  two  seconds  per  aircraft.  This  reduced  the  telemetry  and 
waypoint  download  lag  times.  It  is  not  clear  if  the  communications  lag  is  due  to  packet 
collisions  or  a  reduced  polling  rate,  but  the  constant  stream  of  commands  to  the  aircraft 
has  the  same  effect  as  adding  more  agents  to  the  system. 

The  team  observed  one  other  communications  phenomenon  when  testing  Mr. 
Smith’s  collision  avoidance  algorithm  [36],  His  program  monitored  telemetry  data  from 
aircraft  until  a  potential  collision  threshold  was  crossed.  Then,  the  program  generated 
pitch,  turn  rate,  and  airspeed  commands  to  the  aircraft  at  the  rate  of  the  received 
telemetry  packets.  Similar  to  the  results  from  Capt  Booth’s  tests,  the  team  noticed  a 
slowdown  of  received  telemetry  during  the  algorithm  tests,  but  the  team  also  saw  another 
effect.  The  commands  appeared  to  be  generated  at  a  higher  rate  than  could  be  processed 
by  the  system,  resulting  in  a  queue  of  commands.  The  aircraft  could  not  be  manually 
commanded  to  other  navigation  modes  while  the  commands  in  the  queue  were  being 
processed.  Also,  the  aircraft  designated  for  manual  control  could  not  be  changed.  This 
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caused  a  loss  of  operator  control  over  the  vehicles,  although  the  commands  in  the  queue 
could  still  be  overridden  by  manual  inputs  from  the  RC  controller.  The  size  of  the  queue 
and  corresponding  length  of  control  loss  varied  with  the  amount  of  time  of  each  collision 
encounter,  apparently  related  to  the  time  the  algorithm  was  actively  generating 
commands. 

Video  Reception 

In  addition  to  autopilot  communications,  the  team  tested  the  ability  to  receive  and 
display  four  simultaneous  video  feeds.  The  test  setup  was  ultimately  successful  in  this 
effort,  as  seen  in  Figure  13,  but  the  team  encountered  numerous  problems.  First, 
hardware  malfunctions  in  aircraft  cameras  and  camera  pod  connections  caused  there  to  be 
less  than  four  fully  functional  aircraft  on  all  but  the  last  flight  test  date.  Second,  the  sheer 
amount  of  equipment  used  in  video  reception  and  capture  made  for  a  very  complex  and 
less  reliable  system.  The  number  of  connections  between  pieces  of  equipment  was 
upwards  of  40  components,  depending  on  the  exact  configuration.  Troubleshooting  loose 
connections  and  hardware  settings  was  difficult.  Lastly,  even  when  all  the  equipment  and 
connections  were  working,  the  video  from  the  BATCAMs  was  not  of  good  quality. 

Video  distortion  also  occurred  whenever  the  aircraft  faced  towards  or  away  from  the 
ground  antennas  due  to  the  orientation  of  the  video  antenna  on  the  aircraft.  Also,  the 
lateral  instability  noted  in  the  aircraft  performance  section  was  apparent  even  after 
thorough  aircraft  tuning.  This  caused  the  video  image  to  constantly  move  as  the 
BATCAM  rolled  and  was  particularly  noticeable  when  using  the  side  cameras. 

The  Quad  Video  device  used  to  generate  the  split-screen  display  was  useful  in 
simultaneously  capturing  four  video  sources.  However,  limitations  of  this 
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implementation  are  that  each  video  source  cannot  be  recorded  separately  and  the  overall 
resolution  of  each  screen  is  reduced  when  more  than  one  feed  is  displayed  on  the  same 
screen.  To  attempt  to  overcome  these  limitations,  the  team  tested  a  Swann  USB  2.0  DVR 
Guardian™  multi-source  video  capture  device.  This  component  accepted  four  analog 
video  signals,  converted  them  to  digital  streams,  and  transmitted  them  to  the  computer 
through  a  single  USB  cable.  The  included  software  performed  the  functions  of  the  Quad 
Video  and  DVR  hardware,  displaying  the  feeds  in  various  formats  and  recording  them 
independently;  however,  the  USB  connection  was  a  limiting  factor  in  video  bandwidth. 
When  four  video  feeds  were  connected,  the  frame  rate  dropped  to  an  unacceptably  low 
level  of  around  2-3  Hz.  Though  there  are  card-based  video  capture  solutions  that  can 
handle  multiple  video  sources  at  high  frame  rates,  this  is  the  only  type  of  all-in-one 
commercial  solution  the  team  found  for  capturing  multiple  video  streams  to  a  laptop. 
Unfortunately,  it  does  not  appear  viable  for  an  aerial  surveillance  system  due  to  the  poor 
frame  rate. 

System  Impact. 

Communications  limitations  are  a  large  concern  to  a  system  like  the  CUSS.  The 
above  test  results  show  that  increasing  the  number  of  aircraft  to  achieve  surveillance 
objectives  carries  a  significant  consequence  in  terms  of  communications  bandwidth  used. 
The  chosen  communications  scheme  must  balance  data  rates  with  data  integrity.  As  the 
number  of  aircraft  is  increased,  structured  communications,  such  as  polling  or  set 
transmission  time  slots,  become  more  important  in  ensuring  packet  deconfliction. 

The  increased  communications  load  from  Capt  Booth  and  Mr.  Smith’s  algorithms 
also  suggests  that  this  type  of  tight,  centralized  control  is  not  ideal  for  preserving 
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bandwidth.  Any  implementation  of  the  CUSS  should  strive  to  minimize  this  load  by 
reducing  the  amount  of  data  passed,  the  rate  of  commands,  or  possibly  decentralizing  the 
control  algorithms  to  the  individual  aircraft. 

Limitations  from  hardware/software  implementations,  such  as  the  command 
queue  observed  in  Mr.  Smith’s  tests,  can  have  significant  impacts  on  system 
performance.  This  type  of  scheme  should  be  avoided  in  any  function  that  is  significantly 
time  dependent  or  where  human  override  control  must  be  maintained.  A  more  sensible 
plan  for  tight  control  of  UAVs  overwrites  the  current  command  with  the  latest  received 
command,  rather  than  storing  it  in  a  queue. 

The  complexity  of  the  video  capture  system  affects  the  portability  and  reliability 
of  the  fielded  components.  The  performance  of  the  system  must  be  balanced  against  the 
size  and  weight  requirements  for  the  intended  user.  The  test  video  setup  was  not  portable 
or  reliable.  Additionally,  the  performance  of  the  control  system  can  greatly  affect  the 
quality  of  the  collected  sensor  data,  not  just  in  terms  of  platform  stability,  but  also  from 
the  ability  to  place  the  aircraft  and  sensor  in  the  optimal  position  to  observe  the  target. 

Human  Factors  Observations. 

Though  no  specific  human  factors  studies  were  performed,  the  team  recorded 
several  observations  during  the  course  of  ground  and  flight  testing. 

Operator  Workload. 

The  team  was  very  concerned  with  the  workload  on  the  ground  station  operator 
during  testing  for  safety  concerns.  The  pilot  with  the  RC  controller  could  override  the 
autopilot  if  something  went  wrong,  but  could  only  control  one  aircraft  at  a  time.  The 
team  developed  very  specific  test  procedures  to  ensure  that  the  aircraft  in  the  most  critical 
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phase  of  flight  (e.g.  closest  to  the  ground,  taking-off,  landing,  etc.)  was  designated  as 
ready  for  manual  control.  This  designation  was  made  by  clicking  in  a  checkbox  under 
the  “RC”  column  in  the  agent  list  of  Virtual  Cockpit™,  shown  in  Figure  51.  Having  to 
keep  track  of  designating  the  appropriate  aircraft  and  communicating  this  to  the  pilot  was 
initially  a  significant  burden  on  the  operator  and  often  became  confusing.  However,  as 
the  team  got  used  to  the  procedures  and  expectations  were  established,  this  became  less 
of  a  factor. 
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Figure  51.  Virtual  Cockpit™  Agent  List 


In  a  similar  vein,  to  manually  send  commands  to  an  aircraft  from  Virtual 
Cockpit™,  the  appropriate  aircraft  had  to  be  highlighted  in  the  agent  list.  In  Figure  51, 
aircraft  #  4  is  highlighted.  The  fact  that  the  “RC”  checkbox  was  independent  from  the 
highlighted  agent  added  to  the  confusion  of  controlling  multiple  aircraft. 

The  tracking  of  aircraft  parameters  was  less  of  a  factor.  The  aircraft  position  was 
displayed  as  a  graphic  overlay  on  the  map  screen,  as  shown  in  Figure  52.  Additionally, 
the  aircraft  could  be  color  coded  to  tell  them  apart,  and  key  telemetry  data  (agent  number, 
altitude,  airspeed)  could  be  displayed  next  to  their  icons.  The  fact  that  altitude  was  only 
displayed  digitally,  and  not  graphically,  did  make  it  difficult  to  simultaneously  monitor 
multiple  aircraft  altitudes.  In  all  cases,  the  observers  visually  monitoring  the  aircraft 
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noticed  uncommanded  altitude  changes  well  before  the  operator  controlling  Virtual 
Cockpit™. 


Figure  52.  Virtual  Cockpit™  Map  Screen 


Once  the  operator  became  familiar  with  the  interface  and  procedures  for 
controlling  multiple  aircraft,  that  person  reported  that  the  task  of  conducting  a  four-ship 
flight  was  not  difficult.  However,  until  the  aircraft  were  established  in  a  set  pattern  such 
as  an  orbit  or  series  of  waypoints,  the  operator  paid  almost  no  attention  to  the  video 
display  from  the  aircraft  cameras.  Tasks  such  as  launching  and  recovering  aircraft, 
changing  aircraft  altitudes,  and  running  test  algorithms  completely  distracted  the  operator 
from  monitoring  the  aircraft  sensors. 

Trust  in  Automation. 

During  the  course  of  flight  testing,  the  Virtual  Cockpit™  operator  made 
observations  about  trust  in  the  system.  This  is  directly  related  to  operator  workload  in 
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that  a  greater  degree  of  trust  results  in  less  monitoring  of  automated  tasks  and  more  time 
to  devote  to  conducting  and  monitoring  the  surveillance  mission. 

One  example  of  a  poor  design  choice  that  led  to  a  lack  of  trust  was  the  automatic 
landing  mode  for  the  Kestrel™  autopilot.  When  “Land”  mode  is  selected  in  Virtual 
Cockpit™,  the  aircraft  proceeds  through  a  series  of  steps,  governed  by  the  “Rally”  and 
“Land”  points  in  its  flight  plan.  These  points  are  shown  in  Figure  52,  labeled  “R”  and 
“L”  respectively.  First,  the  aircraft  flies  to  the  Rally  point  at  its  current  altitude  and 
begins  to  orbit.  Once  it  reaches  the  orbit,  it  descends  to  a  preset  altitude  known  as  the 
“break  altitude.”  The  aircraft  then  levels  out  at  the  break  altitude  and  continues  around 
the  orbit  to  the  side  opposite  the  landing  point.  It  then  turns  to  line  up  with  the  course 
between  the  Rally  and  Land  points  and  descends  to  follow  a  glideslope  from  the  break 
altitude  at  the  Rally  point  to  the  ground  at  the  Land  point.  However,  Virtual  Cockpit™ 
gives  no  indication  as  to  the  sub-modes  of  the  aircraft  through  this  process.  Therefore, 
the  operator  and  pilot  often  found  themselves  confused  as  to  whether  the  aircraft  was 
lining  up  on  final  or  performing  another  orbit  at  the  Rally  point.  This  was  distracting, 
confusing,  and  created  doubt  about  whether  the  aircraft  was  performing  as  it  should. 

Another  example  came  from  the  implementation  of  Capt  Booth’s  cooperative 
control  algorithm  [34],  In  order  to  get  the  generated  waypoints  to  the  aircraft  quickly  and 
get  them  moving  on  the  desired  paths  from  his  algorithm,  his  interface  sent  waypoint 
packets  directly  to  the  aircraft,  rather  than  as  a  packaged  flight  plan  through  Virtual 
Cockpit™.  This  resulted  in  a  state  where  the  aircraft  had  received  the  new  waypoints, 
but  the  waypoints  displayed  on  the  Virtual  Cockpit™  interface  were  from  the  old  flight 
plan.  This  was  procedurally  remedied  by  the  operator  manually  requesting  a  download  of 
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waypoints  from  each  aircraft  to  Virtual  Cockpit™.  However,  the  mismatch  that  existed 
before  this  step  was  complete  again  decreased  trust  in  the  system. 

System  Impact. 

Human  Factors  considerations  must  be  designed  into  a  system  like  the  CUSS.  A 
well  designed  user  interface  and  control  scheme  will  help  the  operator  conduct  missions 
more  efficiently.  In  the  case  of  a  single  operator,  this  will  allow  more  time  to  monitor  the 
surveillance  sensor  feeds.  Decreased  operator  workload  becomes  even  more  critical  as 
the  number  of  aircraft  controlled  increases  and  the  environmental  conditions  of  the 
operator  (e.g.  temperature,  restrictive  clothing,  enemy  fire,  etc.)  worsen.  An  additional 
part  of  human  factors  considerations  is  required  improvements  to  systems  trust  that  allow 
the  operator  to  concentrate  on  the  mission  tasks  rather  than  focusing  attention  on 
automated  processes.  Enough  information  must  be  available  to  facilitate  system  trust,  but 
it  must  be  presented  in  a  way  that  is  not  overwhelming  to  the  user.  For  example,  the 
landing  sub-mode  could  be  displayed  by  mousing  over  the  “Land”  mode  indicator  button. 
Also,  the  system  should  not  take  control  away  from  the  operator  unless  for  a  well 
thought-out  safety  reason. 

Risk  Areas 

During  the  evaluation  of  the  CUSS  conceptual  architecture  and  flight  testing,  a 
number  of  risk  areas  where  identified  that  impact  the  future  feasibility  and  ultimate 
capability  of  UAS  operations.  While  the  scope  of  this  effort  did  not  include  in-depth 
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research  in  each  of  the  following  areas,  these  concerns  and  issues  will  require 
consideration  to  fully  implement  an  effective  operational  cooperative  control  capability. 

UAS  Performance. 

For  this  thesis,  the  BATCAM  was  government  provided  hardware  and  the  only 
platform  available  to  the  team  in  sufficient  quantities  to  test  cooperative  control  behavior. 
While  this  airframe  is  simple,  small  in  size,  and  requires  a  minimal  logistical  footprint, 
several  significant  limitations  were  identified  during  its  use.  Although  the  BATCAM  is 
readily  man-packable,  its  small  size  and  weight  make  this  airframe  very  susceptible  to 
winds.  Compared  to  the  heavier  and  larger  SIG  Rascal  airframe  used  by  Capt  Farrell  [33] 
and  ENS  Vantrease  [31],  the  BATCAM  had  a  difficult  time  achieving  programmed 
waypoints  and  maintaining  acceptable  airframe  stability  as  identified  during  the  flight 
testing  of  Capt  Farrell’s  algorithm.  Future  use  of  this  test  bed  system  will  require 
evaluation  of  actual  wind  speeds  observed  during  flight  testing  and  their  impact  on 
obtaining  useable  data.  The  development  of  future  software  algorithms  associated  with 
mission  planning  and  execution  should  also  carefully  consider  both  UAV  capabilities  and 
sensor  requirements  to  ensure  the  composite  system  is  able  to  deliver  the  types  and 
quantity  of  data  requested  from  the  mission  tasking. 

Endurance. 

The  BATCAMs  may  be  suitable  for  short  duration  and  quick-look  surveillance 
observation  of  a  target,  but  their  utility  for  longer  duration  missions  or  operating  at 
extended  distances  diminishes  due  to  the  overhead  times  associated  with  launch, 
recovery,  and  travel  time  to  the  target.  To  field  a  UAS  capable  of  cooperative  control 
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behavior,  higher  endurance  platforms  are  necessary  to  provide  ISR  collection  capability 
at  extended  ranges  and  for  long  loiter  times. 

In  a  scenario  where  an  operator  is  tasked  to  provide  persistent  surveillance  on  a 
stationary  target,  a  formation  of  four  vehicles  could  be  used  to  provide  assured  coverage. 
Assuming  an  average  of  two  minutes  to  launch  each  vehicle  in  the  four-ship  formation, 
one  minute  of  transit  time  to  station,  and  one  minute  to  recover  each  vehicle  at  the  end  of 
the  mission,  total  four  ship  coverage  of  the  target,  assuming  20  minute  endurance,  is  only 
12  minutes.  This  is  shown  in  Figure  53. 
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Figure  53.  Four  Ship  Persistent  Surveillance  Scenario  -  Small  Battery 


Assuming  a  40  minute  endurance  with  the  larger  2100  mAh  batteries,  time  over 
target  with  a  4-ship  formation  would  increase  to  32  minutes  as  shown  in  Figure  54. 
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Figure  54.  Four  Ship  Persistent  Surveillance  Scenario  -  Large  Battery 


Comm  unications. 

Communications  Bottleneck. 

Throughout  flight  testing,  the  team  encountered  a  number  of  situations  where  a 
communications  bottleneck  occurred.  This  phenomenon  was  especially  apparent  during 
flight  testing  of  Capt  Booth’s  cooperative  control  algorithm  Mr.  Smith’s  collision 
avoidance  algorithm,  as  previously  discussed.  In  order  to  mitigate  this  risk,  future 
research  must  be  conducted  regarding  how  to  increase  processing  power  on  the  airframe 
and  ground  station,  increase  channel  bandwidth,  separate  commands,  telemetry,  and 
sensor  data  by  frequency,  or  restrict  the  amount  and  rate  of  control  data  to  the  minimum 
that  can  be  reliably  processed. 

Digital  v.s'.  Analog  Sensor  Data. 

One  way  to  restrict  the  data  flow  of  the  system  is  to  reduce  the  amount  of  sensor 
data  being  transmitted  from  the  airframe  to  the  ground  station.  The  system,  in  its  current 
configuration,  transmits  analog  sensor  data  from  each  airframe.  As  the  number  of 
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airframes  increases,  the  reliability  of  the  sensor  video  display  decreases.  In  order  to 
mitigate  this  risk,  the  team  recommends  research  into  transmission  of  digital  sensor  data 
from  each  airframe  to  reduce  the  amount  of  bandwidth  consumed  by  sensor  data 
transmission. 

C2  &  Data  Relay  Capability. 

Real-world  UAS  operation  would  likely  require  cooperative  formations  to  fly  at 
extended  distances  and  operate  in  an  environment  where  they  are  beyond  line-of-sight  of 
the  operator.  In  each  of  these  scenarios,  it  may  be  necessary  for  one  or  more  UAVs 
within  the  formation  to  operate  as  a  two-way  relay  platform  between  other  UAVs  and  the 
ground  station.  This  capability  would  greatly  expand  the  types  of  missions  UASs  can  be 
tasked  to  do,  but  would  also  introduce  additional  challenges. 

One  of  the  largest  risks  with  using  UAVs  as  relay  platforms  is  the  potential  for  a 
communications  bottleneck  at  the  relay  node.  If  communications  traffic  exceeds  the 
capability  of  the  relay  node,  communication  packets  and  vital  navigation  data  may  be 
dropped,  which  could  lead  to  a  lost  communications  scenarios  and/or  loss  of  a  vehicle. 
Additionally,  mission  data  collected  by  the  formation  might  also  be  delayed  or  dropped 
enroute  to  the  ground  station,  potentially  resulting  in  serious  consequences  to  the 
operators  receiving  and  acting  upon  the  mission  data. 

Although  the  MaxStream  modem  has  an  advertised  range  of  14  miles  and 
includes  a  relay  capability  to  pass  C2  and  mission  data  between  platforms  and  the  ground 
station,  the  team  never  fully  investigated  this  functionality.  Throughout  flight  testing,  the 
team  kept  the  BATCAMs  within  visual  range  and  limited  flights  to  less  than  a  0.5  mile 
radius  of  the  ground  station  at  all  times.  Although  the  team  performed  a  satisfactory 
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stationary  ground  test  with  1.55  miles  between  the  BATCAM  and  the  ground  station, 
further  evaluation  of  the  performance  range  and  relay  capability  of  this  modem  is 
required  to  mitigate  the  risks  associated  with  long  range  communications. 

Secure  Communications. 

Real-world  UAS  operations  would  also  likely  require  data  encryption,  especially 
in  hostile  territory.  In  turn,  data  encryption  creates  technical  and  logistical  problems  that 
must  be  addressed  at  the  Theater  level  or  higher.  At  the  system  level,  encryption  also 
creates  additional  data  overhead  which  could  create  or  exacerbate  some  of  the 
communications  problems  described  in  the  previous  sections.  A  thorough  evaluation  of 
throughput  limitations  must  be  conducted  prior  to  implementing  any  encryption  scheme 
with  this  system. 

Distributed  vs.  Centralized  Processing. 

An  alternate  solution  to  reducing  communication  flow  between  the  base  station 
and  multiple  UASs  is  increasing  the  processing  power  onboard  each  UAS,  and  better 
utilizing  distributed  algorithms  for  navigation  and  formation  management.  Dr.  Derek 
Kingston,  for  example,  has  researched  the  feasibility  of  a  distributed  solution  to 
optimizing  surveillance  of  a  path  with  multiple  UAVs  [26], 

Procerus  advertises  the  ability  to  reprogram  its  autopilot,  but  the  team  did  not 
investigate  this  capability.  Future  teams  examining  the  distributed  algorithm  approach 
would  need  to  research  using  the  autopilot  processor  to  execute  control  algorithms, 
adding  additional  processing  power  to  the  autopilot,  or  adding  an  external  processor  to 
the  aircraft. 


112 


Video  Capture  Limitations. 

Digitally  converting  the  video  signal  of  four  individual  video  streams  and  sending 
those  four  images  to  a  single  laptop  created  a  communications  bottleneck  at  the  USB 
port,  resulting  in  an  unacceptable  frame  rate  on  the  video  display.  This  problem  was 
circumvented  by  either  viewing  the  video  streams  on  an  external  device,  or  combining 
the  four  feeds  into  a  single  quad- format  display.  The  problem  with  the  former  solution  is 
portability.  The  problem  with  the  latter  solution  is  the  inability  of  the  user  to  manipulate 
or  isolate  any  single  stream.  Future  research  into  sensor  data  throughput  and  video 
capture  technology  must  be  conducted  if  the  ground  system  is  to  be  operated  solely  from 
a  laptop  computing  device. 

Human  Factors  Issues. 

System  Trust. 

With  any  remote  operation  of  UASs,  system  trust,  or  confidence  in  the  system  to 
do  what  the  operator  expects  it  to  do,  becomes  an  important  factor.  When  flying  a  single 
UAV,  the  operator  is  able  to  concentrate  his  or  her  efforts  on  ensuring  the  UAV  is 
executing  the  assigned  tasking  and  quickly  correcting  any  anomalous  behavior.  As  the 
number  of  airborne  UAVs  increases,  operator  attention  is  divided  and  it  becomes  difficult 
to  monitor  every  aspect  of  UAS  operation.  Although  the  test  bed  proved  to  be  a  reliable 
and  robust  system  for  flying  up  to  four  UAVs  simultaneously,  Mr.  Smith’s  and  Capt 
Booth’s  algorithms  still  stressed  the  test  bed’s  ability  to  effectively  pass  command  and 
telemetry  data  between  the  BATCAMs  and  ground  station. 

Future  utilization  of  the  test  bed  should  include  interfaces  and  algorithms  that 
provide  positive  feedback  to  the  operator.  This  includes  acknowledging  acceptance  of 
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command  inputs  and  quickly  notifying  the  operator  of  changes  in  aircraft  or  algorithm 
condition  or  state.  Future  algorithms  should  also  include  an  override  function  that 
restores  immediate  control  to  both  the  operator  and  safety  pilot  in  the  event  that  a 
command  or  telemetry  bottleneck  impairs  communication  with  the  UAS. 

Effective  Formation  and  Sensor  Management. 

The  test  bed  systems  also  identified  the  difficulties  of  operating  the  UAVs  while 
simultaneously  viewing  the  video  feed  provided  by  each  platform.  While  the  test  bed 
was  capable  of  displaying  the  video  feed  on  the  same  screen  as  critical  aircraft  status 
information  and  algorithm  information,  additional  human  factors  research  is  required  to 
determine  exactly  how  many  aircraft  and  the  amount  of  information  than  can  reasonably 
be  processed  by  a  single  operator.  Mitigation  of  this  problem  may  involve  separating 
system  and  sensor  operator  responsibilities  between  two  or  more  individuals  for  more 
effective  management  of  cooperative  control  platforms. 

Interfaces. 

Proper  interfaces  are  essential  when  dealing  with  any  system  designed  to  be 
compatible  with  various  types  of  hardware.  The  CUSS  concept  envisions  controlling 
multiple  types  of  UAVs  and  sensors  through  common  hardware.  The  physical  and 
logical  interfaces  used  to  gather  aircraft  and  sensor  status,  transmit  collected  sensor  data, 
and  pass  aircraft  and  sensor  control  commands  should  ideally  be  standardized;  however, 
it  may  not  be  practical  to  do  so  on  the  aircraft  side  due  to  the  wide  variety  of  UAVs 
currently  in  use.  One  potential  solution  is  to  use  multiple  “flavors”  of  CUSS  airborne 
hardware  in  order  to  accommodate  the  various  aircraft  sizes,  power  configurations,  and 
interface  types  available  within  the  DoD  UAV  inventory. 
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Similarly,  to  be  compatible  with  multiple  ground  station  setups,  the  CUSS  would 
need  to  handle  differing  operating  systems,  processor  and  memory  capabilities,  and 
communication  port  configurations.  Again,  multiple  “flavors”  of  CUSS  ground  hardware 
may  be  required  to  handle  different  computer  and  communications  antenna  arrangements. 
This  also  may  be  required  to  keep  overall  size  and  weight  to  a  minimum  for  a  man- 
portable  setup,  while  offering  increased  capabilities  at  the  cost  of  increased  size  and 
weight  for  a  larger,  fixed-base  setup. 

Integration  into  the  National  Airspace  System. 

Current  FAA  regulations  prohibit  the  operation  of  any  government  controlled 
UAVs  within  the  NAS  unless  flight  operations  occur  in  restricted  air  space  or  the  FAA 
grants  a  specific  authorization.  This  places  significant  restrictions  on  flight  testing  of 
UASs  and  can  hinder  their  development.  UAS  developers  can  continue  to  push  the  FAA 
towards  establishing  reasonable  flight  rules,  but  they  must  also  examine  measures  to 
make  UASs  more  compatible  with  the  current  NAS.  This  includes  installing  equipment 
like  transponders  as  well  as  developing  flight  safety  technologies  like  active  traffic 
detection  and  avoidance. 
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V.  Summary  and  Recommendations 


Summary 

The  goals  of  this  thesis  were  to  develop  a  conceptual  systems  architecture  to 
address  current  capability  gaps  and  user  needs  associated  with  providing  cooperative 
control  of  multiple  UAVs  from  a  single  control  unit  and  provide  a  test  bed  for  concurrent 
and  future  research  associated  with  cooperative  control  of  multiple  UAVs. 

In  addition  to  expanding  upon  these  goals,  Chapter  I  addressed  the  scope  and 
assumptions  of  the  thesis.  Chapter  II  provided  background  on  the  broader  ISR  mission 
that  this  system  is  designed  to  support,  a  brief  history  and  description  of  UAVs  and 
UASs,  a  description  of  the  growing  demand  for  UASs  in  a  number  of  areas,  a  description 
of  cooperative  control,  and  a  recap  of  recent  and  concurrent  research  of  UASs  and  their 
employment  in  a  number  of  operational  scenarios.  Chapter  III  described  the 
methodology  that  the  team  used  to  develop  the  conceptual  and  test  architecture  products 
depicted  in  this  thesis,  the  components  used  to  build  the  test  bed  system,  the  procedures 
used  to  conduct  ground  and  flight  testing  for  this  system,  and  the  technological  risks 
associated  with  this  and  future  flight  tests.  Chapter  IV  detailed  the  architectural  products 
created  by  the  team  in  support  of  this  thesis,  the  results  of  flight  testing,  the  performance 
of  specific  hardware  and  software  components  associated  with  the  test  bed  system,  and  an 
analysis  of  risk  areas  identified  throughout  the  process. 
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Remarks 


This  thesis  expanded  on  previous  UAV  research,  specifically  research  conducted 
at  AFIT  by  LCDR  Sakryd  and  Capt  Ericson  [29],  and  Maj  Laird,  et  al.  [28].  The  team 
produced  a  conceptual  architecture  to  address  a  broader  area  of  current  and  future 
research  and  a  test  architecture  to  describe  the  system  constructed  for  the  flight  tests 
conducted  in  support  of  this  thesis.  The  conceptual  architecture  is  not  tied  to  any 
particular  aerial  or  ground  platform  and  is  therefore  highly  scalable.  The  test  architecture 
and  associated  test  bed  were  also  constructed  to  address  specific  areas  of  the  conceptual 
architecture  the  team  intended  to  validate. 

Over  a  period  of  six  months,  the  team  conducted  a  series  of  five  flight  tests  in 
support  of  this  thesis.  Throughout  the  flight  testing  process,  the  team  successfully 
demonstrated  the  ability  to  fly  multiple  UAVs  from  a  single  ground  station  and  the  ability 
to  incorporate  cooperative  control  algorithms  developed  in  concurrent  research. 

Recommendations 

Seek  UAV  Operations  at  WPAFB. 

Due  to  current  FAA  restrictions,  the  team  had  to  conduct  all  flight  testing  at  Camp 
Atterbury,  near  Edinburgh,  IN,  nearly  160  miles  away  from  WPAFB.  While  the  lack  of 
proximity  of  the  flight  test  site  to  WPAFB  did  not  prevent  the  team  from  successfully 
completing  all  flight  testing  required  to  support  this  thesis,  the  logistics  associated  with 
planning  and  conducting  flight  test  at  such  a  remote  location  proved  to  be  a  significant 
obstacle  to  addressing  problems  associated  with  and  discovered  during  flight  testing.  To 
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expand  flight  test  prospects,  personnel  within  AFRL/XPTT,  with  support  from  AFIT,  are 
awaiting  FAA  regulation  changes  that  would  allow  UAV  flight  operations  to  resume  at 
Wright  Patterson  AFB.  Future  research  teams  should  periodically  contact  AFRL/XPTT 
to  obtain  the  latest  status  of  this  effort  and  provide  amplifying  data  as  necessary  to 
encourage  UAV  flight  operations  in  other  than  restricted  airspace. 

Reexamine  Airframe  Selection. 

The  BATCAM  UAV  was  chosen  due  to  its  small  logistical  footprint,  its 
availability  to  the  test  team,  and  the  GOTS  hardware  and  software  available  to  support 
ground  and  flight  testing.  While  flight  testing  was  considered  successful  using  this 
airframe,  the  SIG  Rascal  airframe  used  in  previous  testing  proved  to  be  a  more  stable 
platform.  Of  particular  concern  to  the  test  team  was  the  lateral  stability  associated  with 
the  BATCAM,  and  the  susceptibility  of  the  BATCAM  to  high  or  gusty  winds  due  to  its 
light  weight  and  slow  cruising  airspeeds.  The  team  recommends  investigating  the  use  of 
a  more  stable  airframe  for  future  flight  testing. 

If  the  decision  is  made  to  continue  use  of  the  BATCAM,  the  team  recommends 
performing  another  round  of  autopilot  tuning.  Further  refining  the  PID  values  for  the 
autopilot  control  loops  could  result  in  a  more  stable  platform  for  testing  student- 
developed  control  algorithms. 

Create  a  Robust/Common  Development  Interface. 

Based  on  the  research  of  LCDR  Sakryd  and  Capt  Ericson  [29],  the  team  chose  to 
use  the  C++  development  interface  provided  in  the  Virtual  Cockpit™  software 
development  kit  as  a  basis  for  the  algorithm  interfaces  developed  by  Capt  Booth  and  Mr. 
Smith.  Each  algorithm  tested  with  the  system,  however,  used  a  different  interface  to 
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interact  with  Virtual  Cockpit™.  While  the  interfaces  proved  successful  in  ground  and 
flight  testing,  each  was  extraordinarily  sensitive  to  changes  in  packet  structure  associated 
with  the  two  different  versions  of  Virtual  Cockpit™  used  during  the  flight  test  program. 
The  team  recommends  the  development  of  a  common  Model-View-Controller  based 
interface,  tailorable  to  individual  algorithm  needs.  By  maintaining  a  common  controller, 
future  researchers  can  adapt  the  model  to  changes  associated  with  Virtual  Cockpit™ 
software  updates,  and  the  view  based  on  user  needs  and  preferences  without  having  to 
change  the  basic  functionality  of  the  controller  portion  of  the  software. 

Utilize  the  Latest  Hardware  and  Software. 

The  current  Kestrel  autopilot  is  very  adaptable  to  a  number  of  platforms,  and 
Procerus  publishes  frequent  updates  to  its  software  to  improve  functionality  and  provide 
new  features.  Although  product  support  is  readily  available  through  Procerus  for  current 
versions  of  their  products,  support  for  previous  versions  of  hardware  and  software  is 
limited.  As  a  result,  this  team  recommends  flying  the  latest  version  of  available  products 
to  ensure  some  level  of  product  support  is  available  through  Procerus.  Moreover,  future 
researchers  should  conduct  periodic  reviews  of  available  autopilot  products  to  determine 
if  better  systems  exist  for  advancing  UAS  cooperative  control  capability  and 
technologies. 

Investigate  On-Board  Processing  Power  and  Implementation. 

Based  on  the  packaged  configuration  of  Virtual  Cockpit™,  most  of  the  processing 
involved  with  airframe  control  and  algorithm  implementation  was  conducted  at  the 
ground  station.  Bandwidth  became  an  increasingly  significant  risk  area  as  the  number  of 
airframes  and  the  complexity  of  the  control  algorithms  increased.  This  risk  was  mitigated 
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somewhat  by  the  implementation  of  a  polling  feature  included  in  Virtual  Cockpit™  to 
reduce  the  amount  of  lost  data  associated  with  the  packet  collisions  and/or  processing 
delay  created  by  multiple  airframes  communicating  on  a  common  frequency;  however,  as 
demonstrated  by  the  last  flight  test,  communication  bandwidth  issues  still  proved 
significant.  To  reduce  the  effect  of  bandwidth  as  a  limiting  factor  in  control  and 
algorithm  implementation,  the  team  recommends  further  investigation  to  increase  the 
onboard  processing  and  algorithm  computation  capability  of  UAVs  and  future  UASs. 

Future  Areas  of  Study 

Channel  and  Bandwidth  Deconfliction. 

In  addition  to  bandwidth  shared  among  the  multiple  airframes  associated  with  this 
system,  the  team  believes  that  future  users  will  face  channel  deconfliction  issues  with 
other  wireless  communication  systems  within  a  theater  of  operations.  Chief  among  these 
issues  are  adapting  to  established  protocols  already  in  existence  and  mitigating  the  risk  of 
operating  in  the  vicinity  of  systems  not  using  any  established  protocols.  The  team 
recommends  investigation  into  protocols  and  strategies  to  mitigate  these  situations. 
Distributed  vs.  Centralized  Control. 

Distributed  control  of  multiple  airframes  could  significantly  reduce  the 
communications  footprint  associated  with  this  system.  The  team  recommends 
investigation  into  the  feasibility  of  developing  and  implementing  decentralized  control 
algorithms  for  multiple  UAVs. 
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Communication  Relay  Capability. 

Long  distance  and  beyond  line-of-sight  surveillance  will  require  a  relay  capability 
to  issue  control  commands  to,  and  receive  surveillance  data  from  multiple  UAVs.  While 
the  MaxStream  modems  used  in  the  test  bed  system  have  a  relay  capability,  the  use  of 
one  or  more  UAVs  as  a  relay  platform  was  beyond  the  scope  of  this  thesis.  The  team 
recommends  investigating  the  use  of  UAVs  as  effective  relay  platforms  and  the 
development  of  an  architecture  that  would  permit  effective  relay  operations. 

Minimum  Parameter  Set. 

The  team  envisioned  a  control  system  that  can  be  employed  on  multiples  types  of 
vehicles.  To  enable  this,  the  cooperative  control  algorithms  must  be  based  on  a  set  of 
aircraft  parameters,  rather  than  being  tailored  to  a  specific  vehicle.  The  team 
recommends  researching  a  minimum  set  of  parameters  that  characterizes  each  UAV  type 
as  it  interacts  with  the  control  system. 

Operator  Trust  and  Workload. 

Although  the  team  noticed  a  significant  increase  in  operator  workload  as  the 
number  of  airborne  UAVs  increased,  the  human  factors  aspect  of  flight  testing  was 
largely  considered  beyond  the  scope  of  the  thesis.  The  team  recommends  the  future 
investigation  of  human  factors  issues  associated  with  the  control  of  multiple  UAVs  by  a 
single  operator  from  a  single  ground  control  station. 
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Appendix  A:  List  of  Acronyms 


AFB  -  Air  Force  Base 

AFIT  -  Air  Force  Institute  of  Technology 

AFRL  -  Air  Force  Research  Laboratory 

AV  -  All  View 

C2  -  Command  and  Control 

C2ISR  -  Command,  Control,  Intelligence,  Surveillance,  and  Reconnaissance 

C4ISR  -  Command,  Control,  Communications,  Computers,  Intelligence, 

Surveillance,  and  Reconnaissance 

CD  -  Computing  Device 

CCD  -  Charged  Couple  Device 

CDF  -  Cumulative  Distribution  Function 

CESI  -  Cooperative  Engineering  Services  Incorporated 

COCOM  -  Combatant  Command 

COLA  -  Collision  Avoidance 

COTS  -  Commercial  Off-the-Shelf 

CONOPS  -  Concept  of  Operations 

CUSS  -  Cooperative  Unmanned  Surveillance  System 

DHS  -  Department  of  Homeland  Security 

DLL  -  Dynamic-Link  Library 

DoD  -  Department  of  Defense 

DoDAF  -  Department  of  Defense  Architecture  Framework 
DVD  -  Digital  Video  Disk 

DVR  -  Digital  Video  Recorder 
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FAA 


Federal  Aviation  Administration 


FEMA 

-  Federal  Emergency  Management  Agency 

FOB 

Forward  Operating  Base 

FOV 

-  Field  of  View 

GCH 

Ground  Communications  Hardware 

GOTS 

Government  Off  the  Shelf 

GPS 

Global  Positioning  System 

HIL 

Hardware-in-the-Loop 

HQ 

Headquarters 

ICOM 

Input,  Control,  Output,  or  Mechanism 

I/O 

Input/Output 

IP 

Internet  Protocol 

ISR 

Intelligence,  Surveillance,  and  Reconnaissance 

JCIDS 

Joint  Capability  Integration  Development  System 

LiPo 

Lithium  Polymer 

LOC 

Lines  of  Communication 

LOS 

Line-of-Sight 

MAV 

Mini/Micro  Aerial  Vehicle 

MSR 

Main  Supply  Route 

NAS 

-  National  Airspace  System 

OSD 

Office  of  the  Secretary  of  Defense 

OV 

Operational  View 

PID 

Proportional/Integral/Derivative 

POI 

Point  of  Interest 
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PPS 

Packets  Per  Second 

QDR 

Quadrennial  Defense  Review 

RC 

Remote  Controlled 

RF 

Radio  Frequency 

RMS 

Root  Mean  Square 

SAR 

Search  and  Rescue 

SatCom 

Satellite  Communications 

SIL 

Software-in-the-Loop 

SQL 

Structured  Query  Language 

SRB 

Safety  Review  Board 

sv 

Systems  View 

TCP 

Transmission  Control  Protocol 

TRB 

Technical  Review  Board 

TV 

Technical  View 

UAS 

Unmanned  Aircraft  System 

UAV 

Unmanned  Aerial  Vehicle 

USB 

Universal  Serial  Bus 

WPAFB 

Wright-Patterson  Air  Force  Base 
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Appendix  B:  CUSS  Concept  of  Operations 


Purpose 

The  purpose  of  the  Cooperative  Unmanned  Surveillance  System  (CUSS)  is  to 
provide  a  revolutionary  surveillance  capability  to  forward  deployed  users  that  uses 
multiple  UAVs  to  cooperatively  execute  assigned  taskings.  This  system  will  utilize  an 
overarching  architecture  and  common  interface  that  enables  the  command,  control,  and 
communications  to  and  between  multiple  UAVs  simultaneously.  The  CUSS  is  capable  of 
conducting  a  wide  variety  of  UAS  missions  and  will  display  collected  intelligence  data  to 
distributed  users  through  its  common  interface.  The  CUSS  is  also  a  software  intensive 
system  that  will  utilize  common  hardware  components  to  achieve  the  flexibility 
necessary  for  a  variety  of  mission  taskings  and  is  adaptable  to  a  variety  of  aerial 
platforms  and  user  interfaces. 

Time  Horizon,  Assumptions  and  Risks 

Time  Horizon. 

The  CUSS  is  being  designed  in  response  to  current  threats  and  user  needs  from 
the  warfighting  community.  The  capabilities  the  CUSS  will  deliver  are  needed  today  and 
well  into  the  foreseeable  future.  The  concept  CUSS  will  be  demonstrated  by 
developmental  testing  in  early  2009  and  systems  capabilities  will  continue  to  evolve  with 
respect  to  both  technology  and  warfighter  needs  throughout  the  life  of  the  concept.  First 
generation  deployable  CUSSs  are  targeted  for  delivery  within  the  next  three  to  five  years. 
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Assumptions. 

Doctrine. 

The  CUSS  is  expected  to  provide  Combatant  Commands  (COCOMs)  faster  and 
higher  quality  intelligence  data  than  was  previously  available.  As  such,  warfighter 
doctrine  will  need  to  be  updated  across  the  battlefield  to  better  utilize  CUSS  capabilities 
and  increase  the  operational  and  tactical  reach  of  personnel  executing  the  warfighter 
mission.  The  CUSS  will  also  require  that  DoD  component  services  work  in  concert  with 
one  another  to  share  and  utilize  assets  effectively  in  a  combat  theater.  Properly  utilized, 
the  CUSS  also  provides  seamless  interoperability  and  enables  the  sharing  of  assets  among 
distributed  users  to  obtain  the  maximum  intelligence  value  from  available  platforms  and 
sensor  packages. 

Organization. 

The  CUSS  is  designed  to  be  employed  with  UASs  operated  by  deployed  units.  In 
the  cases  of  UAS  hardware  assigned  to  a  theater  of  operation,  the  CUSS  assumes  that  the 
COCOMs  will  effectively  organize  and  distribute  the  assets  to  units  deployed  within  the 
theater. 

Training. 

It  is  assumed  that  appropriate  training  will  be  made  available  for  personnel  to 
effectively  and  efficiently  operate  the  CUSS. 

Materiel. 

The  CUSS  requires  common  hardware  and  software  components  to  be  installed 
within  separately  procured  UAVs.  The  system  is  not  dependent  on  any  particular 
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airframe  and  is  readily  scalable  from  micro  UAVs  to  large  scale  vehicles  currently  in  use. 
Units  or  services  operating  the  CUSS  will  be  responsible  for  procuring  sufficient 
numbers  of  CUSS  components  to  operate  their  UASs. 

Leadership. 

Due  to  the  expanded  intelligence  gathering  and  multi-mission  capabilities  the 
CUSS  provides,  significant  leaps  in  operational  and  tactical  execution  are  expected. 
Leadership  will  be  required  to  train  and  modernize  their  forces  to  fully  utilize  the  new 
capabilities  the  CUSS  will  bring  to  the  battlefield. 

Personnel. 

The  CUSS  will  enable  one  or  two  operators  to  simultaneously  control  a  formation 
of  multiple  UAVs.  As  a  result,  the  overall  number  of  personnel  devoted  to  the  operation 
of  UAVs  will  eventually  decrease  as  the  CUSS  is  fielded. 

Facilities. 

The  CUSS  will  have  a  negligible  impact  on  facilities.  Initially  designed  as  a 
tactical,  readily  expandable  system,  the  CUSS  will  likely  re-utilize  existing  space  already 
in  use  by  other  UASs.  It  is  also  assumed  that  forward  deployed  facilities  will  have  the 
capability  to  store,  maintain,  and  support  CUSS  components. 

Risks. 

Doctrine. 

The  Joint  community  may  not  immediately  embrace  the  capabilities  provide  by 
the  CUSS.  With  current  UAS  operations,  each  service  operates  their  own  type  and  variety 
of  UAVs,  responds  to  their  own  services  taskings,  and  is  not  concerned  for  the  needs  of 
operators  outside  their  own  service  or  unit.  As  a  result,  UAVs  on  today’s  battlefield  are 
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not  interoperable  and  cannot  effectively  work  together  in  a  formation  or  when  combined 
with  another  operational  unit.  The  CUSS  will  enable  users  to  fly  multiple  UAVs 
simultaneously  and  provide  unmatched  surveillance  and  intelligence  gathering  capability. 
Data  collected  by  CUSS  assets  can  then  be  viewed  by  numerous  distributed  users  across 
the  battlefield.  Once  the  usability  and  mission  benefits  of  the  CUSS  are  understood, 
interoperability  concerns  within  the  Joint  community  will  decrease. 

Organization. 

The  CUSS  will  require  more  streamlined  and  direct  control  of  UAV  assets  under 
a  COCOM.  Once  the  mission  capabilities  and  limitations  are  understood,  it  is  expected 
that  necessary  changes  to  UAV  operations  will  be  made  to  optimize  the  use  of  the  CUSS 
and  UAS  assets. 

Training. 

Insufficient  training  on  the  use  of  the  CUSS  will  result  in  less  than  optimal 
surveillance  and  data  collection  capabilities  and  could  result  in  the  loss  of  mission  UAVs. 
Training  and  training  support  will  be  critical  to  the  effective  use  of  the  CUSS. 

Materiel. 

The  CUSS  is  an  integrated  materiel  system  that  requires  sufficient  quantities  of 
hardware,  software,  and  spares  to  effectively  operate.  The  CUSS  will  require  sufficient 
funding  to  realize  the  benefits  it  promises. 

Leadership. 

Leadership  may  become  wary  of  transferring  their  assets  to  another  unit  or 
operational  entity  and  then  later  having  those  assets  returned  to  them  at  the  end  of  a 
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mission.  Top  level  direction  and  experience  with  the  CUSS  will  enable  commanders  to 
appreciate  the  full  complement  of  benefits  the  system  can  provide  to  warfighters. 

Personnel. 

The  CUSS  will  require  an  initial  increase  of  personnel  within  the  UAV 
community  as  it  is  deployed.  Once  the  system  is  operational,  it  is  expected  that  fewer 
operators  will  be  able  to  effectively  operate  more  UAVs  and  lead  to  an  eventual  reduction 
of  personnel  assigned  to  UAV  operations.  However,  a  central  cadre  of  highly  trained 
personnel  will  be  required  to  provide  operational  training  and  technical  support  to  system 
operators. 

Facilities. 

The  CUSS  may  require  a  central  facility  for  handling  repairs,  housing  technical 
support  personnel,  and  generating  training  materials  for  operational  units. 

Military  Challenges 

Mission  Statement. 

Provide  real-time  multiple  UAV  ISR  capability  to  forward  deployed  users  and 
COCOMs.  The  CUSS  will  provide  integrated  command,  control,  and  information 
gathering  capabilities  that  can  be  displayed  to  numerous  users  through  a  common 
interface. 
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Concerns. 


Bandwidth  Limitations. 

The  rapid  growth  of  wireless  systems  on  the  battlefield  will  constrict  the 
availability  of  bandwidth  for  use  by  the  CUSS  and  potentially  limit  its  capability. 

Frequency  Deconfliction  (External). 

The  CUSS  will  likely  compete  with  existing  systems  for  bandwidth  and  frequency 
usage.  Theater-level  coordination  will  be  required  to  manage  the  use  of  the  CUSS  and 
any  other  systems  operating  in  the  wireless  communications  medium. 

Frequency  Deconfliction  (Internal). 

The  CUSS  will  have  multiple  video  and  data  feeds  competing  for  resources  within 
the  scope  of  its  own  allotted  frequencies  and  bandwidth.  Collision  avoidance  algorithms 
and  protocols  will  be  required  to  allow  multiple  resources  to  communicate  on  the  same 
wireless  network. 

Throughput  Limitations. 

The  CUSS  will  require  processing  power  on  both  the  ground  station  and  aircraft 
to  process  multiple  video  and  data  streams.  The  overall  size  and  capability  of  the 
airborne  platform  may  limit  the  quantity,  quality,  and  timeliness  of  intelligence  data 
collected  by  the  CUSS. 

Secure  Communications. 

The  CUSS  will  require  a  secure  communications  network  to  prevent  unauthorized 
or  hostile  interception  of  video  and/or  data  streams. 
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Onboard  vs.  Ground  Processing. 

The  CUSS  will  require  a  tradeoff  study  to  determine  the  optimum  distribution  of 
processing  power  between  the  ground  station  and  UAV  platforms.  Risk  issues  include 
the  weight  of  UAV  platforms,  required  size,  weight  and  power  of  on-board  processors, 
required  foot  print  of  ground  control  stations,  and  impact  to  communications  bandwidth. 

Human  Factors. 

The  CUSS  will  require  a  human  factors  study  to  determine  how  effectively  single 
or  multiple  individuals  can  control  and  monitor  multiple  UAVs  and  video  streams 
simultaneously  from  a  single  interface. 

Size,  Weight,  and  Power. 

The  CUSS  will  require  a  tradeoff  study  to  determine  the  optimum  combination  of 
size,  weight,  and  power,  based  on  user  defined  requirements.  Multiple  versions  of  CUSS 
hardware  may  be  required  to  support  UAVs  and  operational  units  of  various  size, 
capabilities,  and  interfaces. 

System  Maintainability. 

The  CUSS  will  require  forward  deployed  maintenance  capabilities  and  technical 
support  for  both  software  and  hardware  components. 

Synopsis 

The  purpose  of  the  CUSS  is  to  provide  an  agile,  responsive,  and  user-oriented 
airborne  surveillance  system  that  is  focused  on  the  tactical  and  operational  levels  of  war. 
The  CUSS  will  utilize  an  overarching  architecture  that  combines  common  hardware 
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components  with  a  user-friendly  software  system  that  enables  system  operators  to  surveil 
a  variety  of  targets  with  multiple  UAVs.  The  system  is  capable  of  being  controlled  by  a 
single  user  and  displaying  data  to  multiple  distributed  users.  The  system  shares  hardware 
components  and  software  protocols  to  ensure  it  is  expandable  and  interoperable  between 
a  variety  of  UAV  platforms.  The  CUSS  is  not  specific  to  a  single  type  of  UAV  platform 
or  host  computer  system. 

The  primary  components  of  the  system  include:  1)  control  software;  2)  mission 
planning  software;  3)  display  software;  4)  ground  and  airborne  communications 
transceivers;  5)  airborne  processing  and  control  hardware;  6)  and  software  to  produce  an 
exportable  surveillance  product. 

Desired  Effects 

“TiVo”  Capability. 

The  CUSS  will  provide  the  user  the  capability  to  display,  playback,  record,  and 
manipulate  a  sensor  data  stream.  The  system  will  also  enable  this  data  to  be  exported  to 
external  distributed  users. 

Persistent  Surveillance. 

The  CUSS  will  provide  the  user  persistent  surveillance  of  a  route,  search  area,  or 
other  designated  target.  Uninterrupted  coverage  will  allow  a  user  to  examine  a  given  area 
over  an  extended  period  of  time. 
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Enhanced  Sensor  Coverage. 

Through  the  use  of  multiple  UAVs,  the  CUSS  will  provide  improved  sensor 
coverage  and  situational  awareness  above  and  beyond  what  a  single  UAV  platform  can 
provide. 

Reduced  Revisit  Time. 

The  CUSS  will  provide  reduced  revisit  time  of  areas  or  targets  of  interest  through 
the  use  of  multiple  UAV  platforms  and  cooperative  control  algorithms  designed 
specifically  for  a  variety  of  mission  types  and  specialized  tasks. 

Adaptable  Sensor  Coverage. 

The  CUSS  will  provide  variable  and  programmable  sensor  coverage  patterns 
using  a  variety  of  sensor  systems  based  on  mission  taskings. 

Necessary  Capabilities 

Communications  Hardware. 

The  CUSS  requires  hardware  to  send  secure  C2  information  to  and  receive  secure 
position,  telemetry,  and  intelligence  data  from  multiple  UAVs  at  extended  ranges. 
Communications  systems  employed  by  the  CUSS  must  avoid  becoming  saturated  by 
outside  networks  and  should  minimize  the  overall  system  load  placed  on  battlefield 
communications.  Consideration  should  be  given  to  dynamic  assignment  of  bandwidth  as 
well  as  utilization  of  commercial  networks  to  provide  the  secure  communications 
necessary  to  operate  the  CUSS. 
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End  User  Equipment. 

The  CUSS  must  be  compatible  with  existing  C4ISR  networks  and  capable  of 
visualizing,  using,  and  transporting  surveillance  products  created  by  the  CUSS. 

Control  Algorithms. 

The  CUSS  requires  algorithms  to  optimize  control  of  multiple  UAVs  for  various 
tasks.  Tasking  includes,  but  is  not  limited  to,  formation  manipulation,  optimization  of 
coverage  area,  flight  path  deconfliction,  collision  avoidance,  sensor  placement 
optimization,  flight  path  optimization  to  keep  a  target  in  a  UAV’s  fixed  sensor  field-of- 
view,  convergence  of  multiple  UAVs  on  a  single  target,  and  terrain  avoidance. 

Enabling  Capabilities 

Responsive  Launch  and  Recovery. 

The  CUSS  requires  effective  and  efficient  launch  operations  to  initiate  a  mission 
and  provide  sufficient  mission  coverage,  platform  replenishment,  and  persistent 
surveillance  in  response  to  mission  taskings.  Effective  and  responsive  UAV  recovery  is 
also  necessary  to  prepare  for  re-launch  of  mission  platforms  or  for  subsequent  taskings. 
Precision  Geolocation. 

A  precision  source  of  position  and  velocity  data,  such  as  the  Global  Positioning 
System  (GPS),  will  be  required  for  operation  of  the  CUSS.  This  system  will  be  used  to 
calculate  accurate  coordinates  for  all  UAVs  in  a  formation,  provide  waypoints  for  the 
navigation  of  UAVs,  and  describe  target  locations  from  data  collected  by  the  UAVs. 
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Communication  Enablers. 


Sufficient  digital  communication  devices  are  necessary  for  high  rate  data 
transmission  at  beyond  line-of-sight  ranges,  up  to  several  hundred  kilometers.  These 
communications  should  be  capable  of  direct  ground  station  to  UAV  communications,  as 
well  as  UAV  to  UAV  communications  to  enable  the  relaying  of  information  between  the 
ground  station  and  most  distant  UAV. 

Beacon  Following  Capability. 

Beacon  following  technology  must  be  available  to  enable  the  system  to  locate  and 
track  a  fixed  or  moving  target  that  emits  a  detectable  signal.  This  device  will  forward 
GPS  coordinate  information  to  the  ground  system  and  be  used  to  navigate  UAVs  in 
accordance  with  target  movement  and  UAV  formation  plans. 

Host  Computer. 

A  host  computer  with  a  commercially  available  and  maintainable  operating 
system  (such  as  Windows  XP  or  Linux)  and  nominal  processing  power  and  memory  will 
be  required  for  proper  operation  of  the  CUSS  C2. 

UA  V  Platform  and  Sensors. 

Multiple  UAVs  with  a  sensor  package  (such  as  video,  infrared  cameras  or 
synthetic  aperture  radar)  are  required  for  operation  of  the  CUSS.  These  platforms  and 
onboard  sensors  must  be  capable  of  receiving  control  commands  from  the  CUSS 
hardware.  The  platforms  must  be  capable  of  passing  sensor  data  to  the  CUSS  transceiver. 
The  platforms  must  also  have  the  range,  endurance,  flight  characteristics,  and  sensor 
characteristics  specific  to  the  user’s  desired  mission  tasking. 
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Sequenced  Actions 


General  System  Functions. 

General  system  functions  are  inherent  to  all  missions.  Minor  variations  to  these 
functions  are  made  by  the  user  based  upon  multiple  factors,  such  as  mission 
requirements,  terrain,  environment,  or  launch  platform. 

Plan  Mission. 

The  user  begins  the  development  of  a  mission  plan  by  taking  user  defined  inputs 
such  as  ISR  data,  mission  tasking,  mission  data,  airspace  control  measures,  target  list, 
UAS  flight  status,  and  an  asset  list  and  entering  these  into  CUSS  software  hosted  on  the 
Computing  Device  (CD).  The  software  then  develops  and  generates  a  mission  plan  that 
when  executed,  will  achieve  the  overall  mission  objectives.  Once  the  mission  plan  is 
complete,  the  CD  sends  the  information  via  the  Ground  Communications  Hardware 
(GCH)  to  the  UAS.  The  mission  plan  is  typically  uploaded  to  each  UAV  before  launch 
but  real-time  updates  to  the  mission  plan  can  be  forwarded  to  UAVs  at  any  time  after 
launch. 

Deploy  System. 

The  user  wishes  to  deploy  multiple  UAVs.  The  user  sets  up  all  necessary  ground 
support  equipment  and  uploads  a  planned  mission  to  the  UAVs.  The  user  launches  the 
UAS  in  a  direction  dictated  by  wind,  obstacles,  and  mission  requirements.  Once  airborne, 
the  UAS  begins  mission  execution  at  the  direction  of  the  user. 
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Re-plan  Mission. 

While  flying  and  executing  an  existing  mission  plan,  additional  information 
becomes  available  that  requires  a  new  mission  or  re-planning  of  an  existing  mission.  If 
flying  an  existing  mission  plan,  the  user  monitoring  the  CUSS  identifies  a  new  target  of 
interest  or  determines  the  need  for  a  new  mission  tasking.  Mission  plans,  once  generated, 
are  static  until  new  information  requires  an  update  to  the  mission  plan.  A  mission  re-plan 
can  be  initiated  either  by  the  user  or  by  automation,  triggered  by  a  change  in  the  mission 
status,  collected  surveillance  data,  or  new  C2  takings.  This  information  is  loaded  in  the 
CUSS  software  and  is  used  to  generate  a  new  mission  plan  that  results  in  the  re-tasking  of 
mission  assets.  Once  the  plan  is  complete,  the  CD  sends  the  information  via  the  GCH  to 
the  UAS.  The  UAS  then  begins  executing  this  new  mission  plan  and  transmit  the  sensor 
feeds  to  the  user  via  the  CUSS.  The  mission  plan  can  be  uploaded  to  each  UAV  either 
before  launch  or  after  the  UAV  is  airborne  if  an  update  to  the  mission  plan  is  necessary. 

Manage  the  UA  Vs. 

Once  the  UAVs  are  airborne,  the  CUSS  software  and  airborne  control  hardware 
utilizes  the  current  mission  plan,  UAV  system  status,  UAV  positions,  sensor  gimbal 
angles,  and  sensor  commands  to  direct  the  UAV  flight  paths  and  ensure  the  mission  plan 
is  effectively  and  efficiently  being  executed.  This  function  provides  flight  commands  to 
position  the  UAVs  where  needed  and  to  maintain  UAV  position,  ensure  collision 
avoidance  (COLA),  and  optimize  sensor  collection  opportunities  and  geometries.  The 
CUSS  software  will  communicate  via  the  GCH  and  upload  control  commands  to  the 
UAVs  performing  a  mission.  Additionally,  this  function  will  measure  current  UAV 
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telemetry  data,  and  produce  UAV  flight  status  and  mission  status  information  to  be 
monitored  by  the  users. 

Control  Sensors. 

UAS  sensor  control  utilizes  platform  position,  sensor  gimbal  angles,  UAV 
orientation,  target  location,  and  the  current  video  display  to  optimize  coverage  of  the 
target  or  target  area  of  interest.  Combined  with  the  overall  sensor  health,  sensor  status, 
and  user  operator  commands,  UAS  sensor  commands  are  generated  to  direct  the  final 
orientation  and  configuration  of  the  sensors,  such  as  zoom  level,  sensor  modes,  sensor 
tracking  point,  sensor  auto  tracking,  and  sensor  switching  if  multiple  sensors  are  present. 
The  system  has  the  ability  to  conduct  these  functions  automatically  in  accordance  with 
the  mission  plan  or  manually  as  a  result  of  operator  input. 

Manage  Surveillance  Data. 

The  UAS  and  UAS  sensors  work  in  concert  to  collect  and  provide  real-time  data 
that  can  be  displayed  in  a  video  format  to  both  the  operator  controlling  the  system  and  to 
other  distributed  users.  This  function  records,  displays  and  outputs  a  video  stream  for  the 
users  in  addition  to  displaying  UAV  telemetry  data  such  as  UAV  position,  orientation, 
gimbal  angles,  and  target  locations.  The  video  data  may  also  undergo  automatic  analysis 
such  as  automatic  target  recognition,  movement  detection,  change  detection,  object 
counting,  and  target  status  dependent  on  the  capability  of  the  sensor  and  system.  This 
function  provides  the  fidelity  necessary  for  the  operator  to  fully  understand  all  aspects  of 
UAS  health  and  status,  sensor  health,  status  and  modes  and  flight  telemetry  to  enable 
effective  command  and  control  of  all  UAS  and  sensor  functions  to  execute  the  current 
mission  or,  as  necessary,  to  update  and  re-task  an  on-going  mission  as  a  result  of  a  new 
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target  being  identified  or  located.  The  system  provides  tools  for  the  users  to  combine 
recorded  sensor  data  (such  as  a  time-stamped  video  feed  or  still  picture)  with  extracted 
information  (such  as  target  coordinates  and  user  comments)  into  a  finished  surveillance 
product.  This  can  then  be  exported  for  use  by  other  users  and  organizations. 

Manage  Health  and  Status  of  UA  Vs. 

The  system  manages  the  health  and  status  of  each  UAV  tasked  for  a  mission.  If 
the  CUSS  detects  a  warning  condition,  such  as  low  battery,  low  fuel,  or  other  system 
anomaly  the  system  alerts  the  user  to  the  condition  and  recommends  a  course  of  action. 

In  the  event  of  a  low  fuel  or  battery  state,  the  UAV  will  automatically  execute  recovery 
procedures  to  reduce  the  possibility  of  UAV  loss.  If  necessary,  the  user  may  override  this 
function  to  maintain  coverage  over  the  target  area  or  point  of  interest.  The  system  may 
recommend  the  launch  of  a  replacement  UAV.  The  user  can  also  specify  to  replace  the 
tasked  UAV  with  another  airborne  UAV.  If  a  replacement  UAV  arrives  before  the 
malfunctioning  UAV  begins  its  return  to  base,  the  system  replaces  the  malfunctioning 
UAV  with  the  new  UAV.  If  the  malfunctioning  UAV  must  depart  before  the  new  UAV 
arrives,  the  system  calculates  a  new  mission  plan  to  account  for  fewer  airborne  UAVs 
executing  the  mission. 

Recovering  the  System. 

The  user  wishes  to  recover  a  UAV  that  has  completed  or  returned  from  a  mission. 
The  user  sends  recovery  commands  using  the  CUSS  software.  The  CD  sends  mission 
data  to  the  UAS  via  the  GCH.  The  UAS  processes  this  data  and  returns  to  a  specified 
recovery  location.  When  UAS  operations  are  complete,  the  user  disables  and  disconnects 
the  system  as  required,  and  prepares  the  UAS  for  a  follow-on  mission. 
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Conduct  Post  Mission  Actions. 


After  the  completion  of  a  mission,  the  CUSS  will  be  prepared  for  the  next 
mission.  This  may  include  conducting  post  flight  system  checks,  replacing  consumables 
such  as  fuel  and  batteries,  and  conducting  any  necessary  repair  to  the  UAS  or  other  CUSS 
components. 

Employment  Scenarios. 

Surveil  a  Stationary  Target. 

A  user  wishes  to  surveil  a  stationary  target.  The  user  creates  a  mission  plan, 
deploys  the  CUSS,  and  prepares  the  UAVs  for  flight.  Once  the  mission  plan  is  complete 
and  approved,  the  plan  is  transmitted  to  the  UAVs  via  the  GCH.  After  UAS  deployment, 
the  CD  interfaces  with  the  UAV  autopilots  to  guide  the  UAVs  to  the  target  location. 

Upon  reaching  the  target  location,  the  UAVs  perform  a  search,  acquire  the  target,  and  set 
up  a  loiter  flight  pattern  in  accordance  with  the  mission  plan  or  as  designated  by  the  user. 
The  UAVs  maintain  surveillance  and  sensor  coverage  of  the  target.  At  the  end  of  the 
mission,  the  UAVs  are  re-tasked  or  returned  to  their  designated  recovery  location. 

While  over  the  designated  target,  the  user  may  change  the  UAV  and  sensor 
parameters  to  minimize  the  chance  of  detection  of  the  UAVs  or  to  obtain  better  sensor 
geometry  or  resolution  of  the  target.  These  changes  can  be  accomplished  either  through 
sensor  control  commands,  UAV  flight  commands  or  both.  Depending  on  the  type  and 
scope  of  changes  made  by  the  user,  a  new  mission  plan  may  be  generated  and  sent  to  the 
UAVs. 
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Surveil  a  Moving  Target. 

A  user  wishes  to  identify  and/or  follow  a  moving  target,  such  as  a  vehicle,  human 
on  foot,  or  ship.  The  user  first  creates  a  mission  plan  and  then  deploys  the  CUSS  and 
UAS  if  not  already  in  use.  The  CUSS  directs  the  UAVs  to  the  target  location  and 
provides  position  updates  of  the  moving  target  as  they  become  available.  The  UAVs 
transmit  sensor  data  to  the  user.  Upon  reaching  the  specified  location,  the  UAVs  perform 
a  search,  acquire  the  target,  and  set  up  a  loiter  flight  pattern  to  provide  sensor  coverage 
over  the  target  of  interest.  The  user  designates  the  target  on  his  or  her  sensor  monitoring 
screen.  The  UAVs  track  the  designated  target  and  maintain  sensor  coverage  of  the  target. 
If  the  target  moves,  the  UAVs  adjust  flight  paths  to  maintain  coverage.  The  user  attempts 
to  identify  the  target  vehicle  based  on  the  target’s  features,  path  of  motion,  and 
surroundings.  At  the  end  of  the  mission,  the  UAVs  are  returned  to  their  previous  tasks  or 
recovery  location. 

This  scenario  may  be  entered  from  another  surveillance  task.  The  user 
monitoring  UAV  sensor  feeds  identifies  a  vehicular  target  of  further  interest.  The  user 
directs  the  system  to  monitor  the  target.  The  UAV  transitions  to  a  loiter  flight  pattern 
around  the  newly  selected  target. 

The  user  may  change  the  default  loiter  distance  to  minimize  the  chance  of 
detection  of  the  UAV  or  to  try  to  obtain  better  sensor  resolution  or  geometry  angles  on 
the  target. 

If  a  UAV  is  too  slow  to  maintain  coverage  of  a  moving  vehicle,  the  CUSS  alerts 
the  user.  The  system  predicts  the  location  of  the  moving  target  based  on  its  last  known 
location,  direction  of  movement,  and  velocity. 
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Reconnoiter  Ahead  of  a  Moving  Target. 

A  user  wishes  to  maintain  surveillance  ahead  of  a  moving  target  or  convoy  of 
vehicles.  The  user  creates  a  mission  plan  with  the  CUSS  software  and  this  mission  plan 
is  uploaded  to  the  UAVs  via  the  GCH.  After  system  deployment,  the  CUSS  directs  the 
UAVs  to  the  designated  coverage  area  where  the  moving  target  or  convoy  is  located.  The 
CUSS  tracks  the  moving  target  through  the  use  of  a  tracking  beacon  that  transmits  current 
GPS  position  data.  This  GPS  data  is  collected  by  the  UAVs  and  the  CUSS  monitors  the 
position  and  speed  of  the  beacon.  The  system  adjusts  UAV  positioning  to  provide 
desired  coverage  around  the  beacon  in  accordance  with  the  mission  plan  or  user  input. 

The  UAVs  transmit  sensor  data  to  users  operating  the  system  (in  the  convoy  or  at  a  fixed 
base).  At  the  end  of  the  mission,  the  UAVs  return  to  their  recovery  location. 

During  the  mission,  if  a  user  detects  a  point  for  further  study,  the  user  commands 
one  UAV  to  focus  on  that  point.  The  single  UAV  transitions  to  a  loiter  flight  plan  around 
the  selected  point  as  directed  by  the  user.  The  CUSS  redistributes  the  coverage  ahead  of 
the  moving  target  or  convoy  among  the  remaining  UAVs.  When  the  user  directs  the 
system  to  stop  monitoring  the  point  of  interest,  the  CUSS  directs  the  single  UAV  back 
into  the  original  formation  and  redistributes  coverage  assignment  among  the  entire 
formation. 

The  user  may  specify  a  sensor  coverage  displacement,  distance,  or  time  ahead  of 
the  moving  vehicle  for  the  UAVs  to  operate.  The  system  continuously  computes  the 
proper  speed  and  position  for  the  UAVs  to  maintain  the  desired  coverage  based  on  the 
convoy’s  position  and  speed. 
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Provide  Surveillance  of  a  Series  of  Waypoints. 

A  user  wishes  to  provide  surveillance  of  a  series  of  waypoints,  such  as  a  road, 
route,  perimeter,  maritime  transit  lane,  or  geographic  border.  The  user  creates  a  mission 
plan  by  inputting  the  designated  waypoints  into  the  CUSS  software.  The  CUSS  then 
directs  the  UAVs  to  their  initial  waypoints  and  begins  executing  the  desired  mission  plan. 
The  system  manages  the  coverage  of  the  UAVs  until  they  are  directed  to  recover. 

During  the  mission,  if  a  user  detects  a  point  for  further  study,  the  user  commands 
the  UAV  to  focus  on  that  point.  The  UAV  transitions  to  a  loiter  flight  plan  around  the 
designated  point.  The  CUSS  redistributes  the  coverage  along  the  route  among  the 
remaining  UAVs.  When  the  user  directs  the  system  to  stop  monitoring  the  target,  the 
CUSS  directs  the  UAV  back  into  formation  along  the  route  and  redistributes  coverage. 

Conduct  a  Broad  Area  Search. 

A  user  wishes  to  search  a  large  area.  The  user  creates  a  mission  plan  and  uploads 
the  mission  plan  to  the  UAVs  via  the  GCH.  After  deployment,  the  UAVs  fly  to  their  first 
waypoints  in  the  area  of  interest.  The  system  divides  the  coverage  area  and  allocates 
coverage  assignments  among  the  available  UAVs.  The  UAVs  execute  the  mission  plan 
and  transmit  sensor  data  back  to  the  system  operator  or  other  distributed  users.  The 
system  reports  to  the  users  when  the  entire  area  has  been  reconnoitered.  At  the  end  of  the 
mission,  the  UAVs  return  to  their  recovery  location. 

During  the  mission,  if  a  UAV  detects  a  point  for  further  study,  the  user  directs  the 
corresponding  UAV  to  focus  on  that  point.  The  UAV  transitions  to  a  loiter  flight  pattern 
around  the  selected  point  of  interest.  The  system  redistributes  the  remaining  area  to  be 
covered  among  the  remaining  UAVs. 
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The  users  may  change  the  area  of  interest  during  the  mission  through  the  CUSS 
software.  If  this  occurs,  the  CUSS  replans  the  mission  and  recalculates  the  distribution  of 
the  coverage  among  the  UAVs. 

Conduct  a  Search  for  a  Target. 

A  user  wishes  to  conduct  a  target  search,  such  as  for  an  enemy  vehicle  or  downed 
aircrew.  The  user  creates  a  mission  plan  and  deploys  the  system.  The  user  inputs  the 
initial  search  pattern  start  point,  search  pattern  type  (ladder  search,  expanding  square, 
etc.),  and  bounds  on  the  search  area  into  the  CUSS  software.  The  CUSS  creates  a 
mission  plan  and  sends  that  plan  to  the  UAS  via  the  GCH.  Once  deployed,  the  UAVs  fly 
to  the  initial  search  start  point.  The  system  divides  coverage  of  the  search  area  among  the 
UAS  platforms.  The  UAVs  conduct  a  search  of  the  area  and  transmit  sensor  data  back  to 
the  operator  or  other  distributed  users. 

During  the  mission,  if  a  monitor  detects  a  point  for  further  study,  the  operator 
directs  the  corresponding  UAV  to  focus  on  that  point.  The  UAV  transitions  to  a  loiter 
flight  pattern  around  the  selected  target.  The  system  redistributes  the  remaining  area  to 
be  covered  among  the  remaining  UAVs 

Command  Authorities  and  Relationships 

The  CUSS  is  designed  to  be  operated  by  tactical  users  to  support  mission 
requirements.  These  requirements  may  derive  from  the  needs  of  the  tactical  operator  or 
from  a  higher  level  of  command.  To  support  requirements  originating  outside  the  tactical 
units,  the  CUSS  accepts  taskings  and  amplifying  information  from  higher  level  command 
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and  control  authorities.  Once  tasked,  the  tactical  operators  initiate  the  tactical  mission 
plan.  During  mission  execution  the  system  returns  mission  data  and  status  to  higher 
command  authorities  for  the  purpose  asset  tracking,  situational  awareness,  and  relay  of 
collected  ISR  data. 

Summary 

As  combat  experience  and  war-time  use  of  UAVs  increases,  the  DoD  is 
increasingly  relying  on  these  platforms  to  conduct  missions  previously  accomplished  by 
manned  systems  such  as  ISR,  SAR,  and  broad  area  search  missions.  On  today’s 
battlefield,  most  UAVs  operate  independently  and  separately  from  one  another  which 
limits  overall  terrain  coverage  and  timeliness  of  data  to  end  users.  By  effectively 
combining  multiple  UAVs  into  a  cooperative  formation,  COCOMs,  tactical  warfighters, 
and  other  end  users  will  receive  better  situational  awareness,  faster  mission  data,  and 
further  increase  the  variety  of  mission  types  UAVs  are  able  to  accomplish.  The  CUSS  is 
designed  to  facilitate  cooperative  UAS  capabilities  by  enabling  a  common,  scalable 
control  architecture. 
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Appendix  C:  AV-1  Overview  and  Summary  Information 


Identification 

Name:  Cooperative  Unmanned  Aerial  Surveillance  Control  System 

Short  Name:  Cooperative  Unmanned  Surveillance  System  (CUSS) 

Involved  Organizations: 

AFRL/RY 

AFIT/ENV-GSE:  USAF  Graduate  Systems  Engineering  program; 

architecture  developers 

Date:  The  period  of  development  for  this  architecture  was  from  May  2008  - 
February  2009. 

Background 

Current  UAV  operational  effectiveness  and  capability  is  limited  to  using  one 
airborne  platform  at  a  time  to  conduct  an  assigned  mission.  In  response  to  previous 
research  and  extensive  Joint  Capabilities  Integration  and  Development  System  (JCIDS) 
analysis,  cooperative  UASs  composed  of  several  UAVs  were  identified  as  possible 
solutions  to  provide  additional  ISR  capabilities.  By  developing  an  integrated  cooperative 
control  architecture,  UASs  can  accomplish  a  wider  variety  of  ISR  mission  taskings  and 
provide  more  responsive  data  to  warfighters  than  is  currently  possible  with  singular 
UAVs. 
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Purpose 


The  purpose  of  this  effort  is  to  develop  a  flexible  common  architecture  for  multi- 
UAV  cooperative  command  and  control  operations  that  is  scalable  from  man-packable 
systems  up  to  larger  and  longer  endurance  platforms.  This  architecture  is  not  specific  to 
any  particular  type  of  air  vehicle  or  ground  station  setup.  It  is  designed  to  enable  users 
to  plan  cooperative  UAV  missions,  conduct  those  missions  by  directing  UAV  formations 
and  sensors,  and  collect,  process,  and  distribute  data  gathered  from  the  missions. 

Scope 


The  products  associated  with  this  conceptual  architecture  depict  a  scalable  and 
robust  system.  During  the  creation  of  the  prototype  system,  hardware  and  software 
resource  constraints  limited  testing  of  the  conceptual  architecture  to  a  maximum  of  four 
identical  UAVs.  This  evaluation  also  investigated  the  ability  to  simultaneously  control 
multiple  UAVs,  gather  telemetry  and  sensor  data  from  multiple  UAVs,  and  utilize 
separately-developed  control  algorithms  to  perform  various  mission  tasks.  Areas  not 
fully  evaluated  or  requiring  additional  research  are  proposed  as  risk  areas  and 
recommended  as  future  research  topics. 

Time  Frame 

First  generation  deployable  cooperative  UASs  are  targeted  for  delivery  within  the 
next  three  to  five  years. 
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Appendix  D:  AV-2  Integrated  Dictionary 


Introduction 

Integrated  Dictionary  Overview 

The  Integrated  Dictionary  (AV-2)  contains  definitions  of  terms  used  in  the  given 
architecture.  It  consists  of  textual  definitions  in  the  form  of  a  glossary,  a  repository  of 
architecture  data,  their  taxonomies,  and  their  metadata  (i.e.,  data  about  architecture  data), 
including  metadata  for  tailored  products,  associated  with  the  architecture  products 
developed. 

Integrated  Dictionary  Purpose 

The  AV-2  enables  the  set  of  architecture  products  to  stand  alone,  allowing  them  to 
be  read  and  understood  with  minimal  reference  to  outside  resources.  AV-2  is  an 
accompanying  reference  to  other  products,  and  its  value  lies  in  unambiguous  definitions. 
The  key  to  long-term  interoperability  can  reside  in  the  accuracy  and  clarity  of  these 
definitions. 

Integrated  Dictionary  Description 

The  AV-2  defines  terms  used  in  an  architecture,  but  it  is  more  than  a  simple 
glossary.  Many  architectural  products  have  implicit  or  explicit  information  in  the  form  of 
a  glossary,  a  repository  of  architecture  data,  their  taxonomies,  and  their  metadata.  Each 
labeled  item  (e.g.,  icon,  box,  or  connecting  line)  in  the  graphical  representation  should 
have  a  corresponding  entry  in  AV-2.  Each  item  from  a  textual  representation  of  an 
architecture  product  also  has  a  corresponding  entry  in  AV-2. 
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Integrated  Dictionary  Content 


This  table  contains  the  nouns,  entities,  attributes,  relationships,  and  needlines  used 
in  the  CUSS  architecture. 


Table  7.  CUSS  AV-2  Integrated  Dictionary 


Term 

Description 

Origin 

Destination 

A/C  Status 
Interface 

Description:  This  interface  passes  aircraft  telemetry 
and  system  status  information  to  the  Airborne  Control 
Unit.  Telemetry  information  includes  the  aircraft 
position,  velocity,  and  time.  System  status  information 
can  include  fuel  level,  battery  voltage,  or  engine  RPM. 
Type:  Interface 

Views:  SV-1 

Accept  GPS 
Receiver 

Signal 

Description:  This  CUSS  Software  function  interprets 
data  from  an  external  GPS  Receiver.  The  data  provides 
the  position,  velocity,  and  time  of  the  CUSS  Ground 
System.  These  parameters  may  be  used  in  mission 
planning  (to  provide  a  home  location)  or  having  the 

UAVs  follow  the  Ground  System  during  a  mission. 
Reference:  1.3.10 

Views:  SV-4,  SV-5 

ACM 

Boundaries 

Description:  Aircraft  Control  Measure  (ACM) 
boundaries  are  the  physical  operational  envelope  limits 
provided  by  the  C2ISR  node  that  the  UAS  is  not 
allowed  to  exceed.  These  could  include  sovereign 
borders,  kill  boxes,  Restricted  Operating  Zones  (ROZs), 
and  other  limitations  imposed  to  minimize  interference 
with  other  on-going  air  or  ground  operations. 

Type:  ICOM 

Views:  OV-5 

A-2 

A1.2 

Type:  Needline 

Views:  OV-2 

C2ISR 

Node 

CUSS  Node 

ACM 

Restrictions 

Description:  Airspace  Control  Measure  (ACM) 
restrictions  are  established  by  the  C2ISR  node  or  other 
higher  level  authorities  that  restrict  the  operational  flight 
envelope  of  the  UAV.  Examples  of  restrictions  include 
coordination  to  enter  restricted  airspace,  mandated  use 
of  transit  routes,  and  coordination  altitude  guidance. 

Type:  ICOM 

Views:  OV-5 

A-2 

A1.2 

Type:  Needline 

Views:  OV-2 

C2ISR 

Node 

CUSS  Node 
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Term 

Description 

Origin 

Destination 

Activity 

Description:  A  task  or  grouping  of  tasks  that  provides  a 
specialized  capability,  service,  or  product;  OV-5 
diagrams  the  most  significant  task  groupings  that  are  in 
the  resources  lifecycle. 

Type: 

Views: 

Air  Vehicle 

Description:  The  Air  Vehicle  is  the  aircraft  body  that 
carries  the  Sensor  Package  and  CUSS  airborne 
hardware.  It  is  not  fixed  in  size  or  configuration,  but 
refers  to  any  UAV  on  which  the  CUSS  is  installed, 
including  fixed  wing,  rotorcraft,  lighter  than  air,  and 
gliders.  It  includes  the  airframe,  control  surfaces  and 
mechanisms,  propulsion  system,  fuel,  and  power 
system.  The  Air  Vehicle  includes  a  GPS  Receiver  to 
determine  its  position,  velocity,  and  time.  It  may 
include  organic  sensors  that  are  not  part  of  the  mission 
Sensor  Package,  such  as  a  pitot/static  system  or 
temperature  sensor.  It  can  include  health  and  status 
monitoring  equipment,  such  as  fuel  level,  engine  RPM, 
or  battery  voltage.  It  may  also  include  non-CUSS 
communications  hardware,  such  as  an  ATC  transponder. 
The  Air  Vehicle  is  not  supplied  by  the  CUSS. 

Type:  System  Node 

Views:  SV-1 

Airborne 

Antenna 

Interface 

Description:  This  interface  transfers  waveform  data 
between  the  Airborne  Transceiver  and  UAV 
Communications  Antenna(s).  It  operates  by  means  of 

RF  cables. 

Type:  System 

Views:  SV-1 

Airborne 

Control  Unit 

Description:  The  Airborne  Control  Unit  is  a  package  of 
CUSS  hardware  and  firmware  carried  by  the  Air 

Vehicle  that  is  responsible  for  controlling  the  UAV 
platform  and  its  sensors.  This  system  interfaces  with 
the  Airborne  Transceiver  to  send  data  to  and  receive 
data  from  the  ground  station  and  other  CUSS  UAVs.  It 
provides  flight  control  commands  to  and  receives 
vehicle  status  information  from  the  Air  Vehicle.  It  also 
sends  commands  to  and  receives  status  information 
from  the  Sensor  Package.  The  Airborne  Control  Unit  is 
an  integral  component  of  the  CUSS. 

Type:  System 

Views:  SV-1 

Airborne 

System 

Description:  The  Airborne  System  refers  to  the 
collection  of  CUSS  and  non-CUSS  components  co¬ 
located  in  each  UAV.  There  may  be  multiple  instances 
of  the  Airborne  System  (multiple  UAVs).  It  includes 
the  Air  Vehicle,  Sensor  Package,  Airborne  Control  Unit, 
Airborne  Transceiver,  and  the  Communications 

Antenna. 

Type:  System  Node 

Views:  SV-1 
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Term 

Description 

Origin 

Destination 

Airborne 

Transceiver 

Description:  The  Airborne  Transceiver  modulates  data 
from  the  Airborne  Control  Unit  and  Sensor  Package.  It 
also  demodulates  signals  received  by  the 

Communications  Antenna  on  the  UAV  platform.  It  can 
operate  over  multiple  frequencies.  The  Airborne 
Transceiver  is  an  integral  component  of  the  CUSS. 

Type:  System 

Views:  SV-1 

Airborne 

Transceiver 

Interface 

Description:  This  connection  enables  information  from 
the  Airborne  Control  Unit  to  be  sent  to  the  Airborne 
Transceiver  for  transmission  to  the  ground  station  and 
other  CUSS  UAVs.  This  connection  also  allows 
demodulated  data  from  the  ground  station,  reference 
nodes,  or  other  UAVs  to  be  sent  to  the  Airborne  Control 
Unit. 

Type:  Interface 

Views:  SV-1 

Asset  List 

Description:  The  asset  list  includes  all  platforms  and 
sensors  available  to  the  user  for  mission  planning 
purposes.  The  list  includes  capabilities,  limitation, 
availability,  and  location  of  each  asset  to  ensure  a 
complete  and  executable  mission  plan. 

Type:  ICOM 

Views:  OV-5 

A-4 

Al.l 

Type:  Needline 

Views:  OV-2 

Ground 

Logistics 

Node 

CUSS  Node 

C2 

Communica¬ 

tions 

Description:  This  interface  between  the  C2ISR  node 
and  CUSS  Operator.  It  is  used  to  communicate  mission 
tasking,  direction,  and  data  relevant  to  mission  planning 
and  execution  to  the  CUSS  Operator,  or  to  send 
surveillance  products  to  the  C2ISR  node.  It  includes 
face-to-face  interaction,  telephone,  E-mail,  fax,  and 
electronic  chat  services. 

Type:  Interface 

Views:  SV-1 

C2  Link 

Description:  This  interface  is  an  electronic 
communications  link  between  the  C2ISR  node  and  the 
Ground  System  Computing  Device.  It  is  used  to  pass 
mission  tasking,  direction,  and  data  to  the  CUSS 

Software,  and  to  pass  surveillance  products  and  real¬ 
time  mission  information  to  the  C2ISR  node.  The  data 
may  be  passed  over  a  network  such  as  SIPRNet,  or  via 
electronic  media  such  as  digital  video  disks  (DVDs)  or 
flash  drives. 

Type:  Interface 

Views:  SV-1 
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Term 

Description 

Origin 

Destination 

C2ISR 

Description:  This  system  node  communicates  with  the 
CUSS  user  and  Ground  System  Computing  Device  to 
provide  tasking,  reports,  and  other  command  and 
control  information  relevant  to  mission  execution.  It 
encompasses  all  relevant  tasking  and  information 
organizations  such  as  a  platoon  leader,  battalion 
headquarters,  or  Air  and  Space  Operations  Center. 

Type:  System  Node 

Views:  SV-1 

C2ISR  Node 

Description:  Mechanism  that  provides  mission  tasking 
and  direction  to  system  users  and  receives  finished 
surveillance  products  from  CUSS  Operators  and  users. 
Type:  Mechanism  for  A-2 

Views:  OV-2,  OV-5 

N/A 

A-2 

Calculated 

Winds 

Description:  The  CUSS  calculates  wind  speed  and 
direction  for  each  UAV.  This  is  used  to  refine 
formation  management. 

Type:  ICOM 

Views:  OV-5 

A2.4 

A2.3 

Capture 

Surveillance 

Data 

Description:  In  this  function,  the  CUSS  Software 
ensures  that  all  UAS,  sensor,  and  mission  data  is 
collected,  recorded,  and  made  available  for  review  and 
manipulation  by  the  CUSS  Operator. 

Reference:  1.3.4 

Views:  SV-4,  SV-5 

Communica¬ 
tions  Antenna 

Description:  The  Communications  Antenna  broadcasts 
and  receives  electromagnetic  communication  waves.  It 
is  responsible  for  passing  communications  and  sensor 
data  between  each  UAV  and  the  Ground  System.  This 
includes  the  antennas  at  the  ground  station  and  on  each 
aircraft.  It  also  includes  any  additional  amplification 
and  filtering  hardware,  as  well  as  communication  relays. 
The  Communications  Antennas  are  not  supplied  by  the 
CUSS. 

Type:  System 

Views:  SV-1 

Communica¬ 
tions  Link 

Description:  The  communications  link  passes  data 
between  the  UAVs  and  between  the  UAVs  and  the 
ground  station.  It  is  the  electromagnetic  waves  that 
travel  between  the  airborne  and  ground  antennas.  The 
communications  link  does  not  include  information  from 
the  sensor  feeds. 

Type:  Interface 

Views:  SV-1 

Compute 
Mission  Plan 

Description:  This  CUSS  Software  function  describes 
the  computation  and  creation  of  a  fully  executable 
mission  plan.  This  includes  calculations  of  time,  fuel 
consumption,  sensor  coverage,  and  optimized  routes. 
Reference:  1.3.6 

Views:  SV-4,  SV-5 
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Term 

Description 

Origin 

Destination 

Compute 

Navigation 

Solution 

Description:  This  function  describes  how  the  Airborne 
Control  Unit  calculates  the  UAV  flight  route  to  achieve 
parameters  of  the  mission  plan,  desired  formation 
position,  and  desired  sensor  coverage.  The  Airborne 
Control  Unit  computes  desired  aircraft  parameters  such 
as  airspeed,  aircraft  orientation,  and  flight  path  angle. 
Reference:  2.1.6 

Views:  SV-4,  SV-5 

Compute 

Sensor  Control 
Commands 

Description:  In  this  function,  the  CUSS  Software 
generates  directives  to  manage  UAV  sensors,  command 
sensor  track  on  points  of  interest,  or  directly  control 
sensor  pointing  angles  and  settings.  The  CUSS 

Software  then  communicates  these  commands  to  the 

UAV  sensors  through  data  packets  sent  to  the  Ground 
Transceiver. 

Reference:  1.3.9 

Views:  SV-4,  SV-5 

Compute 

Sensor 

Solution 

Description:  This  function  describes  how  the  Airborne 
Control  Unit  calculates  the  correct  sensor  gimbal  angles 
necessary  to  keep  the  point  of  interest  within  the  sensor 
field  of  view.  The  Airborne  Control  Unit  compares  the 
UAV  position  and  orientation  with  the  coordinates  of 
the  point  of  interest  to  compute  these  angles. 

Reference:  2.1.7 

Views:  SV-4,  SV-5 

Compute  UAV 

Control 

Commands 

Description:  In  this  function,  the  CUSS  Software 
generates  directives  to  manage  the  UAV  formation, 
navigate  the  UAVs,  or  directly  control  individual 

UAVs.  The  CUSS  Software  then  communicates  these 
commands  to  the  UAVs  through  data  packets  sent  to  the 
Ground  Transceiver. 

Reference:  1.3.8 

Views:  SV-4,  SV-5 

Computing 

Device 

Description:  The  Computing  Device  hosts  the  CUSS 
Software  and  provides  interfaces  with  the  Operator, 
C2ISR,  and  communications  hardware.  It  includes  the 
processor,  electronic  storage,  one  or  more  display 
devices,  input  devices,  printing  devices,  and  data  ports. 
The  Computing  Device  can  be  a  laptop  or  desktop 
system,  and  is  not  supplied  by  the  CUSS. 

Type:  System 

Views:  SV-1 

Computing 

Device 

Interface 

Description:  The  Computing  Device  interface  is  the 
mechanism  by  which  the  user  interacts  with  the  CUSS 
Software  through  the  Computing  Device.  This  includes 
standard  human/computer  interfaces  such  as  a  keyboard, 
mouse,  and  one  or  more  monitors.  It  may  also  include 
an  analog  control  pad,  touch-screen,  or  other  input 
device. 

Type:  Interface 

Views:  SV-1 
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Term 

Description 

Origin 

Destination 

Conduct 

Mission 

Description:  This  function  is  responsible  for  tracking 
the  overall  execution  of  the  mission.  The  UAV 
position,  velocity,  and  system  status  are  combined  into  a 
real-time  UAV  flight  status.  They  are  also  tracked  over 
time  and  compared  to  the  mission  plan  to  produce  a 
mission  status  with  regard  to  accomplishing  the  mission 
tasking. 

Type:  Function  A2.1 

Views:  OV-5 

A2.1 

A2.1 

Control 

Sensors 

Description:  This  function  generates  commands  to 
control  UAV  sensor  orientation  and  settings  to 
accomplish  the  mission.  It  ensures  the  UAV  sensors  are 
properly  oriented  to  collect  data,  including  tracking  a 
point  of  interest.  This  function  also  monitors  sensor 
health  and  status  during  flight  operations,  and  provides 
a  means  to  adjust  the  sensor  configuration,  such  as 
power,  zoom,  focus,  or  mode. 

Type:  Function  A3 

Views:  OV-2,  OV-5,  SV-5 

A3 

A3 

CUSS  Node 

Description:  The  CUSS  node  is  the  mechanism  that 
enables  multiple  UAVs  to  provide  cooperative 
surveillance  capability.  This  node  is  composed  of 

Ground  System  components  and  Airborne  System 
components  to  enable  the  effective  mission  planning, 
controlling  of  sensors,  and  management  of  UAV 
platforms  and  surveillance  data  collected  by  the  UAS. 
Type:  Mechanism  for  AO 

Views:  OV-2,  OV-5,  SV-1 

N/A 

AO 

CUSS 

Software 

Description:  The  CUSS  Software  resides  on  the 
Computing  Device  and  provides  the  necessary 
capabilities  to  plan  a  mission,  manage  UAVs,  control 
platform  sensors,  and  manage  the  surveillance  data 
collected  by  system  assets.  It  is  designed  to  be 
compatible  with  a  wide  range  of  operating  systems  and 
Computing  Device  hardware  configurations.  The  CUSS 
Software  is  an  integral  component  of  the  CUSS. 

Type:  System 

Views:  SV-1 

Demodulate 
Communicatio 
n  Data 

Description:  This  function  performed  by  the  Airborne 
Transceiver  takes  waveform  communications  data 
received  by  the  Airborne  System  Communications 
Antenna  and  demodulates  that  information.  The  data  is 
then  packetized  and  sent  to  the  Airborne  Control  Unit. 
Reference:  2.2.1 

Views:  SV-4,  SV-5 

Demodulate 
Communica¬ 
tion  Data  from 
UAVs 

Description:  This  function  performed  by  the  Ground 
Transceiver  takes  waveform  communications  data 
received  by  the  Ground  System  Communications 

Antenna  and  demodulates  that  information.  The  data  is 
then  packetized  and  sent  to  the  CUSS  Software,  via  the 
Computing  Device. 

Reference:  1.2.1 

Views:  SV-4,  SV-5 
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Term 

Description 

Origin 

Destination 

Demodulate 

Reference 

Signal 

Description:  This  function  performed  by  the  Airborne 
Transceiver  takes  waveform  Reference  node  data 
received  by  the  Airborne  System  Communications 
Antenna  and  demodulates  that  information.  The  data  is 
then  packetized  and  sent  to  the  Airborne  Control  Unit. 
Reference:  2.2.2 

Views:  SV-4,  SV-5 

Demodulate 
Sensor  Data 
from  UAVs 

Description:  This  function  performed  by  the  Ground 
Transceiver  takes  waveform  sensor  data  received  by  the 
Ground  System  Communications  Antenna  and 
demodulates  that  information.  The  data  is  then 
packetized  and  sent  to  the  CUSS  Software,  via  the 
Computing  Device. 

Reference:  1.2.2 

Views:  SV-4,  SV-5 

Desired 

Gimbal  Angle 

Description:  The  sensor  gimbal  angle  in  the  aircraft 
body  reference  frame  needed  to  aim  the  sensor  at  the 
selected  point  of  interest. 

Type:  ICOM 

Views:  OV-5 

A3. 2 

A3. 3 

Environmental 

Constraints 

Description:  A  set  of  limitations  imposed  on  the  flight 
area  of  the  UAVs,  including  restricted  airspace,  threat 
areas,  or  sovereign  borders.  This  is  primarily  used  to 
dictate  navigation  routes  when  generating  the  mission 
plan.  These  constraints  may  also  drive  the  selection  of 
resources  for  a  specific  mission. 

Type:  ICOM 

Views:  OV-5 

A1.2 

Al.l 

A1.4 

Environmental 

Data 

Description:  The  set  of  specific  coordinates  defining 
areas  or  boundaries  of  known  environmental 
constraints. 

Type:  ICOM 

Views:  OV-5 

A1.3 

A1.4 

Flight  Control 
Interface 

Description:  The  flight  control  interface  enables 
communication  between  the  Airborne  Control  Unit  and 
the  Air  Vehicle  control  surfaces  and  propulsion  system. 
This  connection  sends  commands  to  move  the  flight 
control  surfaces  or  change  the  throttle  setting. 

Type:  Interface 

Views:  SV-1 

Formation 
Position  Error 

Description:  The  difference  between  the  actual  and 
desired  formation  position  for  each  UAV.  The  error 
includes  lateral  position,  altitude,  and  velocity  vector 
differences.  This  error  is  used  to  navigate  the  UAV. 
Type:  ICOM 

Views:  OV-5 

A2.3 

A2.4 
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Term 

Description 

Origin 

Destination 

Generate 

Control 

Commands 

Description:  This  function  generates  signals  to  the 
control  surfaces  and  power  plant(s)  to  control  aircraft 
flight.  It  utilizes  UAV  flight  path  angles,  position,  and 
velocity  to  create  the  control  signals  required  to  achieve 
the  proper  course,  heading  and  speed  in  accordance  with 
navigation  and  user  flight  commands. 

Type:  Function  A2.4 

Views:  OV-5 

A2.4 

A2.4 

Generate 
Mission  Plan 

Description:  This  function  uses  the  mission  resource 
list,  environmental  data  and  mission  parameters  to 
create  a  fully  executable  mission  plan.  The  combination 
of  these  elements  is  dictated  by  environmental 
constraints  and  mission  taskings.  This  function  also 
produces  planning  alerts  to  inform  the  user  of  any 
constraints  in  the  platform  or  sensor  selection  that 
would  keep  the  system  from  achieving  mission 
objectives. 

Type:  Function  A  1.4 

Views:  OV-2,  OV-5 

A1.4 

A1.4 

Generate 

Sensor 

Commands 

Description:  This  function  generates  signals  sent  to  the 
UAV  sensor  to  reposition  or  reconfigure  it.  During 
tracking,  desired  gimbal  angles  are  compared  to 
measured  gimbal  angles  to  generate  movement 
commands.  Direct  sensor  movement  commands  may 
also  come  from  user  inputs.  Other  commands  such  as 
power,  zoom,  or  mode  are  controlled  by  directions  from 
the  Manage  Sensors  function. 

Type:  Function  A3. 3 

Views:  OV-5 

A3. 3 

A3. 3 

Generate 

Surveillance 

Product 

Description:  This  function  describes  the  production  of 
final  surveillance  products  at  the  conclusion  of  a 
mission.  The  CUSS  Software  provides  a  tool  for  the 
CUSS  Operator  to  manipulate  collected  data  into  a 
synergistic  presentation  form. 

Reference:  1.3.5 

Views:  SV-4,  SV-5 

GPS 

Description:  The  GPS  node  provides  the  PNT  data 
necessary  to  calculate  position,  velocity,  and  time  for 
the  UAVs,  ground  station,  reference  node  and  C2ISR 
node.  It  emits  electromagnetic  GPS  signals. 

Type:  System 

Views:  SV-1 

GPS  Interface 

Description:  The  GPS  interface  passes  PNT  data  from 
the  GPS  Receiver  to  the  Computing  Device.  It  operates 
by  means  of  a  standard  computer  data  port,  such  as  a 

USB  2.0  connection. 

Type:  Interface 

Views:  SV-1 

GPS  Node 

Description:  GPS  satellite  system  that  is  the 
mechanism  for  providing  precision  navigation  and 
timing  to  ground  bases  and  airborne  assets  of  the  CUSS. 
Type:  Mechanism  for  A-l 

Views:  OV-2,  OV-5,  SV-1 

N/A 

A-l 
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Term 

Description 

Origin 

Destination 

GPS  Receiver 

Description:  The  GPS  Receiver  is  a  ground-based 
component  that  receives  GPS  signals,  computes  a 
position,  velocity,  and  time,  and  sends  the  data  to  the 
Computing  Device.  It  includes  an  antenna,  receiver, 
and  cable,  and  is  supplied  by  the  unit  that  owns  the 
system. 

Type:  System 

Views:  SV-1 

GPS  Signal 

Description:  The  GPS  signal  is  the  electromagnetic 
waves  emitted  by  GPS  satellites.  These  waves  contain 
data  used  to  calculate  position,  velocity,  and  time. 

Type:  Interface 

Views:  SV-1 

Ground 

Antenna 

Interface 

Description:  This  interface  transfers  waveform  data 
between  the  Ground  Transceiver  and  ground 
Communications  Antenna(s).  It  operates  by  means  of 

RF  cables. 

Type:  Interface 

Views:  SV-1 

Ground 

Communica¬ 

tions 

Hardware 

Description:  The  Ground  Communications  Hardware 
(GCH)  is  the  Ground  System  transceiver  and 
Communications  Antenna  used  to  pass  information 
between  the  Ground  System  and  Airborne  System 
assets. 

Type: 

Views: 

Ground 

Control  Unit 

Description:  The  Ground  Control  Unit  (GCU)  is  the 
combination  of  all  hardware  associated  with  the  CUSS 
Ground  System.  This  includes  the  Operator,  Computing 
Device,  display  devices,  CUSS  Software,  Ground 
Transceiver,  GPS  Receiver,  Communications  Antenna, 
and  any  associated  interfaces  between  these  elements 
and  external  nodes  or  systems. 

Type: 

Views: 

Ground 
Logistics  Node 

Description:  The  ground  logistics  node  provides  UAV 
and  sensor  configuration  prior  to  launch,  in  addition  to 
maintenance  functions  for  the  UAV  platforms. 

Depending  on  mission  profile,  the  ground  logistics  node 
may  also  launch  and  recover  the  UAV  platforms,  and 
transfer  control  with  the  UAS  operator  in  accordance 
with  the  mission  plan. 

Type:  Mechanism  to  A-4 

Views:  OV-2,  OV-5 

N/A 

A-4 

Ground 

System 

Description:  The  Ground  System  refers  to  the 
collection  of  CUSS  and  non-CUSS  components  co¬ 
located  on  the  ground,  and  used  to  control  airborne 
assets  and  produce  surveillance  information.  It  includes 
the  Operator,  Computing  Device,  CUSS  Software, 

Ground  Transceiver,  GPS  Receiver,  and 

Communication  Antenna. 

Type:  System  Node 

Views:  SV-1 

157 


Term 

Description 

Origin 

Destination 

Ground 

Transceiver 

Description:  This  component  modulates  data  packets 
sent  by  the  CUSS  Software  and  demodulates  packets 
received  from  the  airborne  platforms.  It  can  operate 
over  multiple  frequencies  and  receive  multiple  streams 
of  sensor  data.  The  Ground  Transceiver  is  an  integral 
component  of  the  CUSS. 

Type:  System 

Views:  SV-1 

Ground 

Transceiver 

Interface 

Description:  This  interface  transfers  data  between  the 
CUSS  Software  (via  the  Computing  Device)  and  the 
Ground  Transceiver.  It  operates  by  means  of  a  standard 
computer  data  port,  such  as  a  USB  2.0  or  serial 
connection. 

Type:  Interface 

Views:  SV-1 

Interface  with 

Airborne 

Transceiver 

Description:  This  function  describes  how  the  Airborne 
Control  Unit  communicates  with  the  Airborne 
Transceiver.  The  Airborne  Control  Unit  packetizes  data 
for  the  Ground  System  and  other  UAVs,  and  sends  that 
data  to  the  Airborne  Transceiver  through  a  data 
connection.  The  Airborne  Control  Unit  also  receives 
packetized  Ground  System  and  UAV  data  from  the 
Airborne  Transceiver  through  the  same  connection. 
Reference:  2.1.1 

Views:  SV-4,  SV-5 

Interface  with 
C2ISR 

Description:  A  key  function  of  the  system  user  or 
Operator  is  direct  and  frequent  interaction  with  the 

C2ISR  node  during  UAS  mission  planning  and  mission 
execution.  The  user  will  communicate  with  the  C2ISR 
node  during  mission  planning  to  understand  any  mission 
specific  parameters  or  constraints  and  select  necessary 
UAS  and  sensor  assets  available  to  the  user.  During 
mission  execution,  the  user  may  also  interface  with  the 
C2ISR  node  to  modify  the  current  mission  plan  and 
provide  surveillance  product  back  to  this  node  for  use  in 
future  missions. 

Reference:  1.1.6 

Views:  SV-4,  SV-5 

Interface  with 

Ground 

Transceiver 

Description:  This  function  describes  how  the  CUSS 
Software  communicates  with  the  Ground  Transceiver. 

The  CUSS  Software  packetizes  data  for  the  UAVs,  and 
sends  that  data  to  the  Ground  Transceiver  through  a 
standard  data  connection  (such  as  USB  2.0).  The  CUSS 
Software  also  receives  packetized  UAV  and  sensor  data 
from  the  Ground  Transceiver  through  the  same 
connection. 

Reference:  1.3.2 

Views:  SV-4,  SV-5 
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Term 

Description 

Origin 

Destination 

Interpret  Data 

Description:  This  function  transforms  the  real-time  or 
recorded  sensor  and  telemetry  data  into  usable 
information.  Guided  by  the  mission  tasking,  the  user 
generates  flight  and  sensor  commands  or  mission 
retaskings  based  on  this  information.  Target  locations 
and  other  metadata  are  created  from  the  sensor  and 
telemetry  data. 

Type:  Function  A4.3 

Views:  OV-5 

A4.3 

A4.3 

ISR  Alert 

Description:  Time  critical  or  real-time  ISR  data  that 
notifies  the  user  of  potential  threats  to  the  UAS  or  target 
changes.  These  alerts  may  require  a  mission  replan 
dependant  on  the  type  of  alert. 

Type:  ICOM 

Views:  OV-5 

A-2 

A1.2 

Type:  Needline 

Views:  OV-2 

C2ISR 

Node 

CUSS  Node 

ISR  Data 

Description:  ISR  data  is  provided  by  the  C2ISR  node 
and  provides  a  situational  picture  of  the  areas  the  UAS 
will  be  operating  over.  This  information  is  used  to 
identify  any  potential  constraints  to  the  mission  plan. 

ISR  data  may  include  threat  locations  and  types,  flight 
hazard  (such  as  towers  and  cables)  locations,  and  terrain 
data. 

Type:  ICOM 

Views:  OV-5 

A-2 

A1.2 

A1.3 

Type:  Needline 

Views:  OV-2 

C2ISR 

Node 

CUSS  Node 

Manage 

Formation 

Description:  This  function  governs  the  coordination  of 
UAVs  with  respect  to  timing,  lateral  positioning,  and 
altitude.  Formation  includes  any  coordinated  action 
among  UAVs,  regardless  of  their  proximity.  For 
example,  the  formation  could  be  an  equally  spaced 
circle  of  UAVs  around  a  building,  or  the  distribution  of 
UAVs  along  a  lengthy  stretch  of  road.  The  function 
uses  data  from  the  mission  plan,  UAV  position/velocity, 
UAV  system  status,  target  location,  measured  weather 
data,  and  wind  speeds  to  determine  a  desired  formation 
position  for  each  UAV  and  a  formation  position  error. 

The  formation  may  be  governed  by  user  flight 
commands. 

Type:  Function  A2.3 

Views:  OV-5 

A2.3 

A2.3 

Manage 

Sensors 

Description:  This  function  generates  sensor 
management  commands  to  ensure  proper  operation, 
safety,  and  modality  of  the  UAV  sensors.  Sensor 
management  is  controlled  in  response  to  weather,  user 
commands,  and  sensor  status  updates. 

Type:  Function  A3.1 

Views:  OV-5 

A3.1 

A3.1 
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Term 

Description 

Origin 

Destination 

Manage 

Surveillance 

Data 

Description:  This  function  encompasses  the  processing, 
recording,  and  playback  of  collected  data,  the 
interpretation  of  collected  data,  and  the  production  of  an 
exportable  surveillance  product  for  the  operator,  other 
system  users,  or  the  C2ISR  node. 

Type:  Function  A4 

Views:  OV-2,  OV-5,  SV-5 

A4 

A4 

Manage  UAVs 

Description:  Operational  function  that  is  responsible 
for  real-time  command  and  control  of  UAV  flight, 
monitoring  of  health  and  status  of  UAV  assets, 
deconfliction  of  operational  airspace,  and  establishing 
formation  spacing  and  control. 

Type:  Function  A2 

Views:  OV-2,  OV-5,  SV-5 

A2 

A2 

Manipulate 

Surveillance 

Product 

Description:  In  this  function,  the  system  Operator 
directs  the  production  of  a  finished  surveillance  product. 
This  includes  recording  and  playing  back  collected 
sensor  data,  gathering  metadata,  and  combining  data 
into  a  document  that  can  be  printed,  saved  to  electronic 
media,  or  sent  through  network  connections  to  the 

C2ISR  node  or  other  system  users. 

Reference:  1.1.5 

Views:  SV-4,  SV-5 

Measured 
Weather  Alert 

Description:  Measured  Weather  Alert  information  is 
conditions  detected  by  the  UAV  platform  or  sensor 
systems  that  could  affect  the  performance  or  safety  of 
the  aircraft  or  sensors,  or  otherwise  impact  the  mission. 
Alert  information  may  include  high  winds,  icing,  heavy 
precipitation,  or  other  weather  conditions  encountered 
by  the  UAV. 

Type:  ICOM 

Views:  OV-5 

A-4 

A3.1 

Type:  Needline 

Views:  OV-2 

UAV 

Airframe 

Node 

CUSS  Node 

Measured 
Weather  Data 

Description:  Information  on  meteorological  conditions 
collected  by  organic  UAV  sensors  and  sensor  payloads. 
Examples  include  ambient  temperature  and  pressure, 
moisture,  precipitation  detected  by  radar,  winds,  and 
cloud  layers. 

Type:  ICOM 

Views:  OV-5 

A-4 

A2.3 

A2.4 

Type:  Needline 

Views:  OV-2 

UAV 

Airframe 

Node 

CUSS  Node 
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Term 

Description 

Origin 

Destination 

Metadata 

Description:  Usable  information  extracted  from  the 
interpreted  sensor  and  telemetry  data.  The  information 
describes  the  context,  quality,  condition,  or 
characteristics  of  the  data  provided  by  the  UAV 
platforms  and  sensors.  Examples  of  metadata  include 
target  identification,  the  time  an  activity  was  observed, 
or  the  number  of  vehicles  in  an  area. 

Type:  ICOM 

Views:  OV-5 

A4.3 

A4.4 

Mission  Data 

Description:  Mission  Data  is  information  provided  by 
the  C2ISR  node  directly  relevant  to  the  mission  tasking. 
This  data  could  include  timing,  coordinates,  target 
descriptions,  frequencies,  and  other  information 
necessary  to  plan  the  mission. 

Type:  ICOM 

Views:  OV-5 

A-2 

A1.3 

Type:  Needline 

C2ISR 

CUSS  Node 

Views:  OV-2 

Node 

Mission 

Description:  The  set  of  data  that  defines  attributes  key 

A1.3 

A1.4 

Parameters 

to  accomplishing  the  mission  tasking.  This  information 
is  used  to  create  an  executable  mission  plan.  Examples 
of  this  data  include  target  location,  desired  surveillance 
duration,  search  area  boundaries,  desired  revisit  time, 
and  desired  sensor-to-target  line. 

Type:  ICOM 

Views:  OV-5 

Mission  Plan 

Description:  A  set  of  static  elements  used  to  direct 

A1.4 

A2.1 

UAVs  and  sensors  to  conduct  a  surveillance  mission. 

A2.2 

Examples  of  these  elements  include  waypoint  and  target 

A2.3 

locations,  altitudes,  waypoint  commands,  timing 
commands,  formation  types,  and  predicted  mission 
metrics. 

A2.4 

Type:  ICOM 

Views:  OV-5 

Mission 

Description:  The  mission  resource  list  is  a  set  of  UAV 

Al.l 

A1.4 

Resource  List 

and  sensor  assets  selected  by  the  user  and  CUSS  to 
create  an  executable  mission  plan. 

Type:  ICOM 

Views:  OV-5 

Mission  Status 

Description:  The  current  state  of  the  mission  being 

A2.1 

A-2 

executed  with  regards  to  desired  objectives.  During 

Al.l 

mission  execution,  mission  status  is  reported  to  the 

C2ISR  node  and  other  system  users  to  ensure  situational 
awareness.  Mission  status  includes  information  such  as 
percent  of  mission  completed,  area  covered,  total 
number  of  UAVs  operational,  or  other  statistics  of 
interest. 

Type:  ICOM 

Views:  OV-5 

A4.1 

Type:  Needline 

CUSS  Node 

C2ISR 

Views:  OV-2 

Node 
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Term 

Description 

Origin 

Destination 

Mission 

Description:  The  mission  tasking  includes  requirements 

A-2 

Al.l 

Tasking 

passed  down  from  the  C2ISR  node  to  the  CUSS  and  is 

A1.3 

used  to  select  the  appropriate  resources  in  response  to  a 

A1.4 

mission  tasking. 

A2.1 

Type:  ICOM 

A4.2 

Views:  OV-5 

A4.4 

Type:  Needline 

C2ISR 

CUSS  Node 

Views:  OV-2 

Node 

Mission 

Description:  Detected  weather  information  forwarded 

A-2 

A1.2 

Weather  Alert 

by  the  C2ISR  node  of  conditions  that  may  affect  UAS 
operations.  This  information  could  include  storm 
warnings,  changes  in  temperature  or  cloud  cover,  and 
other  conditions  that  may  limit  sensor  or  platform 
performance  and  safety. 

Type:  ICOM 

Views:  OV-5 

Type:  Needline 

C2ISR 

CUSS  Node 

Views:  OV-2 

Node 

Mission 

Description:  Forecasted  and  observed  weather 

A-2 

A1.2 

Weather  Data 

information  provided  by  the  C2ISR  node  that  affects 

UAS  mission  execution.  This  information  may  dictate 
the  type,  quantity,  and  specific  capabilities  of  a  platform 
and  sensor  chosen  for  a  mission.  Mission  weather  data 
includes  temperature,  precipitation,  clouds  layers, 
transmissivity,  and  the  freezing  level. 

Type:  ICOM 

Views:  OV-5 

Type:  Needline 

C2ISR 

CUSS  Node 

Views:  OV-2 

Node 

Modulate 

Description:  This  function  performed  by  the  Airborne 

Communica¬ 

Transceiver  takes  UAV  information  provided  by  the 

tion  Data 

Airborne  Control  Unit,  and  modulates  that  information 
into  a  waveform.  The  waveform  data  is  then  sent  to  the 
Airborne  System  Communications  Antenna  for 
transmission. 

Reference:  2.2.3 

Views:  SV-4,  SV-5 

Modulate 

Description:  This  function  performed  by  the  Ground 

Communica¬ 

Transceiver  takes  both  UAV  and  sensor  commands 

tion  Data  for 

output  by  the  CUSS  Software,  via  the  Computing 

UAVs 

Device,  and  modulates  that  information  into  a 
waveform.  The  waveform  data  is  then  sent  to  the 

Ground  System  Communications  Antenna  for 
transmission. 

Reference:  1.2.1 

Views:  SV-4,  SV-5 
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Term 

Description 

Origin 

Destination 

Modulate 

Sensor  Data 
for  the  GCU 

Description:  This  function  performed  by  the  Airborne 
Transceiver  takes  sensor  information  provided  by  the 
Sensor  Package,  and  modulates  that  information  into  a 
waveform.  The  waveform  data  is  then  sent  to  the 
Airborne  System  Communications  Antenna  for 
transmission. 

Reference:  2.2.4 

Views:  SV-4,  SV-5 

Monitor 

Mission 

Execution 

Description:  This  function  describes  the  Operator 
reviewing  collected  sensor  data  and  UAV  status 
information  to  ensure  the  mission  is  progressing  in 
accordance  with  the  mission  plan.  The  information  is 
displayed  to  the  Operator  via  the  Computing  Device  on 
one  or  more  monitors. 

Reference:  1.1.4 

Views:  SV-4,  SV-5 

Navigate 

UAVs 

Description:  This  function  generates  navigation 
commands  to  fly  the  UAV  to  the  desired  position. 
Navigation  may  be  in  relation  to  a  mission  plan  point,  a 
desired  formation  position,  a  reference  entity,  or  a 
sensor  point  of  interest.  User  flight  commands  may 
dictate  UAV  navigation.  Within  this  function,  each 

UAVs  flight  path  angle  is  calculated  from  CUSS 
sensors  and  UAV  reported  velocity.  Also,  winds  are 
calculated  by  comparing  the  aircraft  orientation  to  its 
flight  path  angle. 

Type:  Function  A2.4 

Views:  OV-5 

A2.4 

A2.4 

Navigation 

Commands 

Description:  Directions  dictating  the  course  and  speed 
of  the  UAV.  Examples  include  climb  to  500  ft,  bank 
left  30  deg,  turn  to  a  heading  of  180  deg,  or  accelerate  to 
25  kts. 

Type:  ICOM 

Views:  OV-5 

A2.4 

A2.5 

Operator 

Description:  The  Operator  is  the  human(s)  responsible 
for  controlling  the  CUSS.  The  Operator  communicates 
with  the  C2ISR  node  and  interacts  with  the  Computing 
Device  to  mission  plan,  control  the  UAVs  and  sensors, 
monitor  the  mission,  and  produce  a  surveillance 
product.  The  Operator  is  an  integral  component  of  the 
CUSS. 

Type:  System 

Views:  SV-1 

Perform 

Airborne 

Control 

Functions 

Description:  This  function  represents  the  aggregate  of 
all  lower  functions  performed  by  the  Airborne  System. 

It  is  the  sum  of  the  sub-functions  Perform  Airborne 
Control  Unit  Functions  and  Perform  Airborne 

Transceiver  Functions. 

Reference:  2. 

Views:  SV-4,  SV-5 
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Term 

Description 

Origin 

Destination 

Perform 

Airborne 

Control  Unit 
Functions 

Description:  This  function  represents  the  aggregate  of 
all  lower  functions  performed  by  the  Airborne  Control 
Unit.  It  is  the  sum  of  the  sub-functions  Interface  with 
Airborne  Transceiver,  receive  Aircraft  Status  Data, 
Receive  Sensor  Status  Data,  Produce  Flight  Control 
Commands,  Produce  Sensor  Control  Commands, 
Compute  Navigation  Solution  and  Compute  Sensor 
Solution. 

Reference:  2.1 

Views:  SV-4,  SV-5 

Perform 

Airborne 

Transceiver 

Function 

Description:  This  function  represents  the  aggregate  of 
all  lower  functions  performed  by  the  Airborne 
Transceiver.  It  is  the  sum  of  the  sub-functions 
Demodulate  Communication  Data,  Demodulate 

Reference  Signal  Data,  Modulate  Communication  Data, 
Modulate  Sensor  Data  for  the  GCU,  and  Transmit  and 
Receive  Modulated  Airborne  Data. 

Reference:  2.2 

Views:  SV-4,  SV-5 

Perform  CUSS 

Software 

Functions 

Description:  This  function  represents  the  aggregate  of 
all  lower  functions  performed  by  the  CUSS  Software.  It 
is  the  sum  of  the  sub-functions  Provide  Operator 

Interface,  Interface  with  Ground  Transceiver,  Provide 
Electronic  C2ISR  Interface,  Capture  surveillance  Data, 
Generate  Surveillance  Product,  Compute  Mission  Plan, 
Track  Mission  Status,  Compute  UAV  Control 

Commands,  Compute  sensor  Control  Command,  and 
Accept  GPS  Receiver  Signal. 

Reference:  1.3 

Views:  SV-4,  SV-5 

Perform 

Ground 

Control 

Functions 

Description:  This  function  represents  the  aggregate  of 
all  lower  functions  performed  by  the  Ground  System.  It 
is  the  sum  of  the  sub-functions  Perform  Operator 
Functions,  Perform  Ground  Transceiver  Functions  and 
Perform  CUSS  Software  Functions. 

Reference:  1. 

Views:  SV-1,  SV-4,  SV-5 

Perform 

Ground 

Transceiver 

Functions 

Description:  This  function  represents  the  aggregate  of 
all  lower  functions  performed  by  the  Ground 

Transceiver.  It  is  the  sum  of  the  sub-functions 

Modulate  Communication  Data  for  UAVs,  Demodulate 
Communication  Data  from  UAVs,  Demodulate  Sensor 
Data  from  UAVs,  Transmit  and  Receive  Modulated 
Ground  Data.  This  function  is  responsible  for  passing 
data  between  the  CUSS  Software,  via  the  Computing 
Device,  and  the  Ground  System  Communications 
Antenna. 

Reference:  1.2 

Views:  SV-4,  SV-5 
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Term 

Description 

Origin 

Destination 

Perform 

Description:  This  function  represents  the  aggregate  of 

Operator 

all  lower  functions  performed  by  the  Operator.  It  is  the 

Functions 

sum  of  the  sub-functions  Provide  UAV  Control  Inputs, 
Provide  Sensor  Control  Inputs,  Provide  Mission 

Planning  Inputs,  Monitor  Mission  Execution, 

Manipulate  Surveillance  Product,  and  Interface  with 
C2ISR. 

Reference:  1.1 

Views:  SV-1 

Plan  Mission 

Description:  This  function  enables  an  operator  to 
produce  a  mission  plan  that  will  be  used  to  direct  UAVs 
and  sensors  to  accomplish  a  mission  tasking.  The  plan 
is  based  on  available  resources,  operational  constraints, 
and  specified  mission  parameters.  Once  created,  this 
plan  is  static,  but  as  the  mission  or  systems  elements 
change,  a  re-plan  can  occur,  establishing  a  new  mission 
plan. 

Type:  Function  A1 

Views:  OV-2,  OV-5,  SV-5 

A1 

A1 

Planning  Alert 

Description:  A  notification  of  constraints  that 

A1.4 

Al.l 

potentially  impact  the  ability  to  accomplish  the  mission. 
The  alert  may  trigger  selecting  new  resources  or  setting 
new  mission  parameters  to  overcome  the  constraints. 

An  example  is  an  insufficient  number  of  UAVs  to 
maintain  the  required  continuous  surveillance  duration. 
Type:  ICOM 

Views:  OV-5 

A1.3 

PNT  Data 

Description:  Precision  radiometric  timing  data  used  by 

A-l 

A-2 

various  nodes  to  determine  location,  time,  and  velocity. 

A-4 

Type:  ICOM 

A-5 

Views:  OV-5 

A1.3 

A2.2 

Type:  Needline 

GPS  Node 

UAV 

Views:  OV-2 

Airframe 

Node, 

Reference 

Node, 

C2ISR 

Node 

Process  Data 

Description:  This  function  continuously  transforms  raw 
data,  such  as  UAV  orientation,  position,  and  velocity, 
sensor  gimbal  angles,  and  sensor  feeds  into  usable  data. 

It  creates  a  video  display  for  the  user  and  an  associated 
telemetry  data  stream.  The  mission  status  dictates  when 
this  function  is  started  and  stopped. 

Type:  Function  A4.1 

Views:  OV-5 

A4.1 

A4.1 
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Term 

Description 

Origin 

Destination 

Produce  Flight 

Control 

Commands 

Description:  In  this  function,  the  Airborne  Control  Unit 
generates  signals  for  the  UAV  flight  controls  and 
throttle.  The  Airborne  Control  Unit  translates  the 
calculated  navigation  commands  into  the  proper  flight 
control  deflections  and  throttle  settings  to  achieve  them. 
Reference:  2.1.4 

Views:  SV-4,  SV-5 

Produce 

Sensor  Control 
Commands 

Description:  In  this  function,  the  Airborne  Control  Unit 
generates  signals  for  the  Sensor  Package.  The  Airborne 
Control  Unit  translates  the  desired  sensor  pointing 
angles  into  commands  to  move  the  sensor  gimbal  to 
achieve  them.  It  also  passes  on  sensor  management 
commands  such  as  changing  sensors,  changing  modes, 
or  zooming  the  sensor. 

Reference:  2.1.5 

Views:  SV-4,  SV-5 

Produce 

Surveillance 

Product 

Description:  This  function  brings  together  all  elements 
of  the  collected  data  to  create  a  completed  surveillance 
product  which  can  be  accessed  by  system  users  and 
exported  to  external  systems.  Recorded  sensor  video, 
derived  target  locations,  and  other  associated  metadata 
is  combined  in  accordance  with  the  objectives  of  the 
mission  tasking. 

Type:  Function  A4.4 

Views:  OV-5 

A4.4 

A4.4 

Provide  C2ISR 

Description:  Function  that  generates  and  disseminates 
ISR  mission  taskings,  relevant  mission  data,  and 
associated  guidance.  The  function  uses  real-time 
mission  updates  and  collected  data  from  UASs  to  update 
C2ISR  data  and  taskings  for  subsequent  missions. 

Type:  Function  A-2 

Views:  OV-2,  OV-5 

A-2 

A-2 

Provide 

Electronic 

C2ISR 

Interface 

Description:  In  this  function,  the  CUSS  Software 
communicates  with  the  C2ISR  node  via  the  C2  Link. 

The  C2ISR  node  sends  guidance  and  data  used  to 
mission  plan  and  conduct  the  surveillance  mission.  The 
CUSS  Software  forwards  surveillance  data  and  mission 
status  information  back  to  the  C2ISR  node  through  the 
interface  as  well. 

Reference:  1.3.3 

Views:  SV-4,  SV-5 

Provide 

Mission 

Planning 

Inputs 

Description:  In  this  function,  the  Operator  provides 
data  and  commands  to  the  CUSS  Software  via  the 
Computing  Device  that  initiate  and  direct  the  mission 
planning  process.  These  inputs  are  used  to  select 
resources,  and  set  mission  constraints  and  parameters. 

The  inputs  from  the  Operator  may  be  based  on  the 
interpretation  of  collected  data. 

Reference:  1.1.3 

Views:  SV-4,  SV-5 
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Term 

Description 

Origin 

Destination 

Provide 

Operator 

Interface 

Description:  In  this  function,  the  CUSS  Software 
provides  an  effective  user  interface  that  enables  all 
system  functions  from  mission  planning,  UAS 
management,  sensor  control,  and  the  management  of 
surveillance  data.  The  interface  includes  displaying 
information  to  the  Operator  on  one  or  more  monitors, 
and  receiving  information  from  the  Operator  through 
input  devices  such  as  a  keyboard,  mouse,  or  analog 
control  pad. 

Reference:  1.3.1 

Views:  SV-4,  SV-5 

Provide  PNT 

Description:  The  function  of  providing  precision 
radiometric  timing  data  to  UAV  platforms,  the  CUSS 
and  reference  nodes  for  the  purposes  of  calculating 
navigation  solutions  and  time  keeping. 

Type:  Function  A-l 

Views:  OV-2,  OV-5 

A-l 

A-l 

Provide 

Reference 

Location 

Description:  This  function  provides  the  geolocated 
coordinates  of  the  reference  source  by  using  PNT  data 
provided  by  the  GPS  node. 

Type:  Function  A-5 

Views:  OV-2,  OV-5 

A-5 

A-5 

Provide  Sensor 
Control  Inputs 

Description:  In  this  function,  the  Operator  provides 
data  and  commands  to  the  CUSS  Software  via  the 
Computing  Device  that  control  the  behavior  of  the  UAV 
sensors.  Based  on  these  inputs,  the  CUSS  can  generate 
control  commands  that  enable  effective  health  and 
status  management  of  the  sensor  systems  and  pointing 
commands,  including  tracking  a  point  of  interest.  The 
inputs  from  the  Operator  may  be  based  on  the 
interpretation  of  collected  data. 

Reference:  1.1.2 

Views:  SV-4,  SV-5 

Provide 

Surveillance 

Description:  The  provide  surveillance  function  is  the 
primary  purpose  of  the  CUSS.  It  includes  all  aspects  of 
planning  surveillance  missions,  managing  the  tasked 
UAVs,  controlling  available  sensors,  and  producing  an 
intelligence  product. 

Type:  Function  AO 

Views:  OV-2,  OV-5,  SV-1 

AO 

AO 

Provide 

Surveillance 

Platform 

Description:  This  function  provides  the  physical 
unmanned  aerial  platform  and  onboard  sensor(s)  as  part 
of  the  UAS.  It  moves  the  sensors  through  the  air  via 
propulsion  and  flight  surfaces  controlled  by  the  CUSS. 

It  is  responsible  for  reporting  the  UAV  position  and 
velocity  to  the  CUSS.  It  also  includes  the  means  to 
launch,  recover,  and  service  the  aircraft. 

Type:  Function  A-4 

Views:  OV-2,  OV-5 

A-4 

A-4 
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Term 

Description 

Origin 

Destination 

Provide 

Targets 

Description:  The  function  of  providing  targets  that  an 
UAS  is  assigned  to  locate  in  accordance  with  the 
mission  plan. 

Type:  Function  A-3 

Views:  OV-2,  OV-5 

A-3 

A-3 

Provide  UAV 
Control  Inputs 

Description:  In  this  function,  the  Operator  provides 
data  and  commands  to  the  CUSS  Software  via  the 
Computing  Device  that  control  the  behavior  of  the 

UAVs.  Based  on  these  inputs,  the  CUSS  can  generate 
control  commands  that  enable  the  tracking  of  a 
reference  point,  management  of  the  UAV  formation,  or 
navigation  of  the  UAVs.  The  inputs  from  the  Operator 
may  be  based  on  the  interpretation  of  collected  data. 
Reference:  1.1.1 

Views:  SV-4,  SV-5 

Receive 

Aircraft  Status 
Data 

Description:  This  function  describes  how  the  Airborne 
Control  Unit  continuously  collects  information  from  the 
Air  Vehicle.  This  data  is  used  by  the  Airborne  Control 
unit  to  navigate  the  UAV  and  generate  commands  for 
the  flight  controls.  It  is  also  passed  on  to  the  Ground 
System  for  use  in  managing  the  formation  and 
monitoring  the  mission. 

Reference:  2.1.2 

Views:  SV-4,  SV-5 

Receive 

Sensor  Status 
Data 

Description:  This  function  describes  how  the  Airborne 
Control  Unit  continuously  collects  information  from  the 
Sensor  Package.  This  data  is  used  directly  by  the 
Airborne  Control  Unit  and  passed  on  to  the  Ground 
System.  It  is  used  to  manage  and  control  the  sensors,  as 
well  as  extract  surveillance  data  (from  the  sensor 
pointing  angles,  for  example). 

Reference:  2.1.3 

Views:  SV-4,  SV-5 

Record  and 
Playback  Data 

Description:  This  function  enables  system  users  to 
store  and  retrieve  processed  data  for  later  interpretation 
and  creation  of  a  finished  surveillance  product.  The 
mission  tasking  may  dictate  which  information  is 
recorded  and  retrieved. 

Type:  Function  A4.2 

Views:  OV-5 

A4.2 

A4.2 

Record 

Telemetry 

Description:  Processed  information  and  statistics 
associated  with  the  sensor  data  that  has  been  stored  by 
the  system.  It  can  be  retrieved  and  interpreted  or  used 
in  the  creation  of  a  finished  surveillance  product. 

Type:  ICOM 

Views:  OV-5 

A4.3 

A4.3 

Recorded 

Video 

Description:  Processed  UAV  sensor  data  that  has  been 
stored  by  the  system.  It  can  be  retrieved  and  interpreted 
or  used  in  the  creation  of  a  finished  surveillance 
product. 

Type:  ICOM 

Views:  OV-5 

A4.2 

A4.3 

A4.4 
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Term 

Description 

Origin 

Destination 

Reference 

Description:  This  system  node  is  able  to  transmit  a 
reference  signal  that  can  be  received  by  the  UAV 
Communications  Antenna.  This  signal  is  used  to  relay 
the  reference  node’s  position  and  velocity. 

Type:  System  Node 

Views:  SV-1 

Reference 

Behavior 

Description:  The  physical  behavior  of  a  reference 
beacon  or  object  that  the  CUSS  must  locate,  track  and 
follow  in  accordance  with  the  mission  plan.  This 
behavior  is  a  product  of  the  entity  (person,  vehicle, 
building)  upon  which  the  beacon  is  located. 

Type:  Control  for  A-5 

Views:  OV-2,  OV-5 

N/A 

A-5 

Reference 

Node 

Description:  An  entity  that  carries  a  reference  beacon 
which  emits  a  signal  that  can  be  tracked  by  the  CUSS  in 
accordance  with  the  mission  plan  or  user  direction. 

Type:  Mechanism  for  A-5 

Views:  OV-2,  OV-5,  SV-1 

N/A 

A-5 

Reference 

Position/Veloc 

ity 

Description:  This  is  the  actual  location  and  velocity 
vector  of  an  entity  being  tracked  by  the  CUSS. 

Type:  ICOM 

Views:  OV-5 

A2.2 

A2.4 

Reference 

Signal 

Description:  The  reference  signal  is  an  electromagnetic 
wave  transmitted  by  the  reference  node  and  received  by 
the  UAV  Communications  Antenna.  It  contains  data  on 
the  current  position  and  velocity  of  the  reference  node. 
Type:  Interface 

Views:  SV-1 

Reference 

Tracking 

Signal 

Description:  A  signal  provided  by  the  reference  node 
that  the  CUSS  can  receive  and  track.  From  this  signal, 
the  CUSS  can  obtain  the  position  and  velocity  of  the 
reference  object,  and  track  this  beacon  in  accordance 
with  the  mission  plan. 

Type:  ICOM 

Views:  OV-5 

A-5 

A2.2 

Type:  Needline 

Views:  OV-2 

Reference 

Node 

CUSS  Node 

Select 

Resources 

Description:  This  function  enables  the  user  to  select 
from  available  resources  the  assets  that  will  be  used  to 
create  an  executable  mission  plan.  The  UAV  and  sensor 
assets  may  be  on  the  ground  or  airborne.  Selection  of 
the  resources  is  dictated  by  the  mission  status,  mission 
tasking,  user  re-tasking  inputs,  planning  alerts,  and 
environmental  constraints.  The  user  selects  the 
resources  necessary  to  execute  the  mission  tasking,  and 
a  mission  resource  list  is  generated  for  the  mission  plan. 
Type:  Function  A  1.1 

Views:  OV-5 

Al.l 

Al.l 
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Term 

Description 

Origin 

Destination 

Sensor  Control 

Description:  The  sensor  control  interface  is  a 

Interface 

standardized  input/output  connection  that  enables  a 
variety  of  sensors  to  interact  with  the  Airborne  Control 
Unit.  Through  this  interface,  the  CUSS  can  control 
sensor  functions,  such  as  gimbal  movement,  zoom,  or 
sensor  switching.  It  also  receives  sensor  status 
information,  such  as  the  gimbal  angles,  zoom  level,  or 
mode. 

Type:  Interface 

Views:  SV-1 

Sensor  Data 

Description:  The  sensor  data  feed  interface  is  a 

Feed  Interface 

standardized  input/output  connection  that  enables 
collected  sensor  information  to  be  sent  to  the  Airborne 

Transceiver. 

Type:  Interface 

Views:  SV-1 

Sensor  Data 

Description:  The  sensor  data  link  passes  sensor  feeds 

Link 

from  the  UAVs  to  the  ground  station.  It  is  the 
electromagnetic  waves  that  travel  from  the  airborne 
antennas  to  the  ground  antenna(s). 

Type:  Interface 

Views:  SV-1 

Sensor  Gimbal 

Description:  The  pointing  angles  of  the  sensor(s)  in 

A-4 

A3. 2 

Angles 

relation  to  the  aircraft  body  frame  of  reference. 

A3. 3 

Type:  ICOM 

Views:  OV-5 

A4.1 

Type:  Needline 

UAV 

CUSS  Node 

Views:  OV-2 

Sensor 

Node 

Sensor 

Description:  Directions  to  ensure  proper  operation, 

A3.1 

A3. 3 

Management 

safety,  and  modality  of  the  UAV  sensors.  Examples 

Commands 

include  turning  on/off,  zooming  in/out,  switching 
between  sensors,  or  changing  modes. 

Type:  ICOM 

Views:  OV-5 

Sensor 

Description:  The  Sensor  Package  is  the  collection 

Package 

asset(s)  carried  by  the  UAV  platform.  It  may  be  fixed 
to  the  Air  Vehicle  or  removable,  but  it  does  not  include 
organic  Air  Vehicle  sensors  such  as  a  pitot/static 
system.  The  sensor  package  transmits  a  collected  data 
stream.  The  Sensor  Package  is  not  supplied  by  the 

CUSS. 

Type:  System  Node 

Views:  SV-1 
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Term 

Description 

Origin 

Destination 

Sensor  Status 

Description:  The  sensor  status  provides  all  necessary 
health  and  status  and  information  for  each  sensor 
onboard  the  UAV.  This  information  includes  sensor 
type,  mode,  voltage,  resolution,  temperature,  faults, 
limitations,  and  other  information  necessary  for  the 

CUSS  or  user  to  manage  the  operation  of  airborne 
sensors. 

Type:  ICOM 

Views:  OV-5 

A-4 

A3.1 

Type:  Needline 

Views:  OV-2 

UAV 

Sensor 

Node 

CUSS  Node 

Sensor 

Tracking  Error 

Description:  A  measurement  of  the  difference  between 
the  desired  and  actual  sensor  orientation  when  tracking 
a  point  of  interest.  This  is  used  to  position  the  UAV  for 
optimized  surveillance  collection. 

Type:  ICOM 

Views:  OV-5 

A3. 2 

A2.4 

Set  Constraints 

Description:  This  function  uses  weather  data,  ACMs, 
and  ISR  data  to  generate  the  boundaries  and  limitations 
the  UAVs  are  allowed  to  operate  within. 

Type:  Function  A  1.2 

Views:  OV-5 

A1.2 

A1.2 

Set  Mission 
Parameters 

Description:  This  function  uses  ISR  data,  known  target 
locations,  and  relevant  mission  data  to  generate  a  set  of 
mission  parameters  used  to  generate  the  mission  plan. 

The  selection  of  mission  parameters  is  dictated  by 
mission  taskings,  user  retaskings,  and  planning  alerts. 
PNT  data  is  used  to  calculate  the  CUSS  home  location, 
which  may  be  used  as  a  mission  parameter. 

Type:  Function  A  1.3 

Views:  OV-5 

A1.3 

A1.3 

Space 

Component 
Guidance  and 
Tasking 

Description:  Context  entity  that  provides  the  resources, 
oversight,  and  management  of  the  GPS  satellite 
constellation. 

Type:  Control  for  A-l 

Views:  OV-5 

N/A 

A-l 

Surveillance 

Product 

Description:  Fully  processed  and  interpreted  data 
becomes  a  surveillance  product  that  is  sent  to  the  C2ISR 
node.  This  data  then  becomes  available  to  other  users, 
and  may  provide  the  basis  for  future  mission  taskings  or 
surveillance  requirements. 

Type:  ICOM 

Views:  OV-5 

A4.4 

A-2 

Type:  Needline 

Views:  OV-2 

CUSS  Node 

C2ISR 

Node 
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Term 

Description 

Origin 

Destination 

Target 

Description:  A  geolocated  position  of  a  point  of  interest 

A4.3 

A1.3 

Location 

derived  from  collected  sensor  data.  The  position  is 

A2.3 

calculated  from  the  designated  location  on  the  sensor 

A2.4 

display,  UAV  position,  sensor  pointing  angle,  and  any 

A3. 2 

ranging  or  topographical  data.  Target  location 
information  can  be  used  to  plan  a  mission  or  be  tracked 
by  the  UAVs  and  sensors. 

Type:  ICOM 

Views:  OV-5 

A4.4 

Target 

Description:  The  physical  characteristics  associated 

A-3 

A-2 

Physical 

with  a  target  such  as  size,  shape,  speed,  color,  and  radar 

A-4 

Characteristics 

signature. 

Type:  ICOM 

Views:  OV-5 

Type:  Needline 

Target  Node 

UAV 

Views:  OV-2 

Sensor 

Node, 

C2ISR 

Node 

Targets 

Description:  Control  attribute  of  the  Provide  Targets 

N/A 

A-3 

Behavior 

function  that  affects  the  location  and  characteristics  of 

system  targets. 

Type:  Control  for  A-3 

Views:  OV-5 

Targets  Node 

Description:  Physical  entity  the  UAS  is  assigned  to 
locate  in  accordance  with  the  mission  plan. 

Type:  Mechanism  for  A-3 

Views:  OV-2,  OV-5 

N/A 

A-3 

Telemetry 

Description:  This  includes  all  of  the  collected 

A4.1 

A4.2 

Data 

information  and  statistics  associated  with  the  raw  sensor 

A4.3 

stream.  It  may  include  information  such  as  time,  UAV 
position,  sensor  pointing  angles,  temperature,  or  other 
metric  of  interest.  It  can  be  recorded  and  played  back 
with  the  associated  video,  and  can  be  interpreted  to 
extract  additional  information  such  as  target  location. 
Type:  ICOM 

Views:  OV-5 

Track  Mission 

Description:  This  CUSS  Software  function  monitors 

Status 

the  conduct  of  a  mission  over  time.  Parameters  and 
statistics  such  as  UAV  locations,  surveillance  coverage 
time,  and  percentage  of  area  covered  are  tracked.  This 
information  is  used  to  guide  the  conduct  of  the  current 
mission  and  may  be  used  to  replan  a  mission  if  required. 
Reference:  1.3.7 

Views:  SV-4,  SV-5 
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Term 

Description 

Origin 

Destination 

Track  POI 

Description:  This  function  enables  the  system  to  track  a 
specific  location  in  the  sensor  field  of  view.  The 
tracking  location  is  designated  from  user  commands  on 
the  video  display  or  from  target  location  coordinates. 

This  data  along  with  the  UAV  position,  velocity,  and 
flight  path  angle  is  used  to  generate  a  desired  gimbal 
angle  to  aim  the  sensor  at  the  point  of  interest. 

Type:  Function  A3. 2 

Views:  OV-5 

A3. 2 

A3. 2 

Track 

Reference 

Point 

Description:  This  function  is  responsible  for  tracking  a 
stationary  or  mobile  entity  to  which  the  UAVs  will 
maneuver  in  relation.  External  entities  are  tracked  via 
the  reference  tracking  signal.  The  CUSS  GCS  can  track 
itself  via  received  PNT  data.  Control  of  which  entity  to 
track  and  when  is  provided  by  user  flight  commands. 

This  function  also  produces  the  position  and  velocity  of 
the  entity  being  tracked. 

Type:  Function  A2.2 

Views:  OV-5 

A2.2 

A2.2 

Transmit  and 
Receive 
Modulated 
Airborne  Data 

Description:  This  function  describes  how  the  Airborne 
Transceiver  sends  and  collects  waveform  data  to  and 
from  the  Airborne  System  Communications  Antenna. 
Reference:  2.2.5 

Views:  SV-4,  SV-5 

Transmit  and 
Receive 
Modulated 
Ground  Data 

Description:  This  function  describes  how  the  Ground 
Transceiver  sends  and  collects  waveform  data  to  and 
from  the  Ground  System  Communications  Antenna. 
Reference:  1.2.2 

Views:  SV-4,  SV-5 

UAV  Airframe 
Node 

Description:  The  UAV  airframe  node  includes  the 
physical  UAV  platforms  used  to  accomplish  the  mission 
plan.  This  node  does  not  include  Sensor  Packages  or 
CUSS  hardware. 

Type:  Mechanism  for  A-4 

Views:  OV-2,  OV-5 

N/A 

A-4 

UAV  Control 
Commands 

Description:  These  are  the  control  surface  and 
propulsion  commands  sent  to  the  UAV  from  the  CUSS 
to  produce  a  desired  airspeed  and  flight  path  orientation 
in  accordance  with  the  mission  plan  or  user  direction. 
Type:  ICOM 

Views:  OV-2,  OV-5 

A2.5 

A-4 
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Term 

Description 

Origin 

Destination 

UAV  Flight 

Description:  A  continuously  updated  set  of  data 

A2.1 

A-2 

Status 

describing  the  state  of  each  UAV  currently  being 
utilized  by  the  system.  This  data  includes  position, 
altitude,  velocity,  fuel  state,  health  status,  and  executing 
command  (e.g.  ”En-route  to  Waypoint  2”  or  ’’Following 
target”).  The  information  is  used  when  creating  a 
mission  plan  involving  assets  currently  in  use  and  for 
providing  the  C2ISR  node  with  situational  awareness  on 
CUSS  assets. 

Type:  ICOM 

Views:  OV-5 

Al.l 

Type:  Needline 

CUSS  Node 

C2ISR 

Views:  OV-2 

Node 

UAV 

Description:  The  orientation  of  the  UAV  in  relation  to 

A2.4 

A2.5 

Orientation 

the  local  horizon  -  heading,  pitch  and  roll  angle.  This 

A3. 2 

information  is  used  to  generate  updated  control 
commands,  navigation  commands,  and  sensor 
commands. 

Type:  ICOM 

Views:  OV-5 

A4.1 

UAV  Position/ 

Description:  Current  and  continuously  updated  UAV 

A-4 

A2.1 

Velocity 

position  and  velocity  information  that  is  derived  from 

A2.3 

GPS  or  other  sources  sent  from  the  aircraft  to  the  CUSS. 

A2.4 

Type:  ICOM 

A2.5 

Views:  OV-5 

A3. 2 

A4.1 

Type:  Needline 

UAV 

CUSS  Node 

Views:  OV-2 

Airframe 

Node 

UAV  Sensor 

Description:  These  are  the  commands  sent  from  the 

A3. 3 

A-4 

Commands 

CUSS  to  the  UAV  sensors  to  direct  the  gimbal  angle, 
turn  on/off,  zoom  in/out  or  perform  other  functions  in 
accordance  with  the  mission  plan  or  user  direction. 

Type:  ICOM 

Views:  OV-5 

Type:  Needline 

CUSS  Node 

UAV 

Views:  OV-2 

Sensor 

Node 

UAV  Sensor 

Description:  The  sensor  feed  data  is  the  raw  bit  stream 

A-4 

A4.1 

Feed 

collected  by  the  sensor  and  transmitted  to  the  CUSS  for 
interpretation  and  production  of  the  final  surveillance 
product. 

Type:  ICOM 

Views:  OV-5 

Type:  Needline 

UAV 

CUSS  Node 

Views:  OV-2 

Sensor 

Node 
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Term 

Description 

Origin 

Destination 

UAV  Sensor 

Description:  The  UAV  sensor  node  is  the  physical 

N/A 

A-4 

Node 

sensor  assets  carried  by  UAVs  dependent  on  the  mission 
tasking. 

Type:  Mechanism  for  A-4 

Views:  OV-2,  OV-5 

UAV  System 

Description:  UAV  System  Status  is  information  about 

A-4 

A2.1 

Status 

resident  UAV  systems  monitored  for  proper  operation. 
This  includes  fuel  level,  voltages,  temperatures, 
pressures,  revolutions,  faults,  and  communication 
throughput. 

Type:  ICOM 

Views:  OV-5 

A2.3 

Type:  Needline 

UAV 

CUSS  Node 

Views:  OV-2 

Airframe 

Node 

User  Flight 

Description:  Directives  from  the  operator  to  control 

A4.3 

A2.2 

Commands 

the  UAVs.  Examples  include  flight  control  surface, 

A2.3 

altitude,  airspeed,  navigation,  formation,  tracking,  and 

A2.4 

mode  commands. 

Type:  ICOM 

Views:  OV-5 

A2.5 

User 

Description:  Directives  from  the  operator  to  change  the 

A4.3 

Al.l 

Retasking 

mission  plan  based  on  interpretation  of  collected  data. 

For  example,  the  CUSS  user  can  retask  system  assets  if 
an  object  or  target  of  interest  is  identified.  This  change 
my  require  new  resources  to  provide  the  collection 
desired. 

Type:  ICOM 

Views:  OV-5 

A1.3 

User  Sensor 

Description:  Directives  from  the  operator  to  control  the 

A4.3 

A3.1 

Commands 

sensors.  Examples  include  slew,  track,  zoom,  and  mode 

A3. 2 

commands,  as  well  as  sensor  selection. 

Type:  ICOM 

Views:  OV-5 

A3. 3 

Video  Display 

Description:  The  video  display  is  the  processed  UAV 

A4.1 

A3. 2 

sensor  data.  It  can  be  displayed  to  the  operator  or  other 

A4.2 

system  users,  recorded  and  played  back,  used  to  control 
sensors,  used  to  designate  targets,  and  combined  with 
other  information  to  construct  a  finished  surveillance 

A4.3 

product. 

Type:  ICOM 

Views:  OV-5 
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Appendix  E:  CUSS  OV-1  Operational  Concept 


Figure  55.  CUSS  OV-1  Operational  Concept 
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Appendix  F:  CUSS  OV-2  Operational  Node  Connectivity  Description 


Figure  56.  CUSS  OV-2  Operational  Node  Connectivity  Description 
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Appendix  G:  CUSS  OV-5  Operational  Activity  Model 
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Figure  57.  CUSS  OV-5  A-0  External  Systems  Diagram 
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Figure  58.  CUSS  OV-5  AO  Context  Diagram 
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CUSS  Node 


Figure  59.  CUSS  OV-5  AO  Provide  Surveillance 
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Target  Location 


Figure  60.  CUSS  OV-5  A1  Plan  Mission 
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Figure  61.  CUSS  OV-5  A2  Manage  UAVs 
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Figure  62.  CUSS  OV-5  A3  Control  Sensors 
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Mission  T asking 


Figure  63.  CUSS  OV-5  A4  Manage  Surveillance  Data 
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Appendix  H:  CUSS  SV-1  System  Interface  Description 


Figure  64.  CUSS  SV-1  System  Interface  Description 
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Appendix  I:  CUSS  SV-4  System  Functionality  Description 


Figure  65.  CUSS  OV-4  System  Functionality  Description 
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Appendix  J:  CUSS  SV-5  Activity  to  Function  Traceability  Matrix 


Table  8.  CUSS  SV-5  Activity  to  Function  Traceability  Matrix 


SV-5 

< 

h 

SYSTEM  FUNCTION  £  £ 

A1  Plan  Mission 

I 

A3  Control  Sensors 

A4  Manage 

Surveillance  Data 

Al.l  Select 

Resources 

A1.2  Set  Constraints 

A1.3  Set  Mission 

Parameters 

A1.4  Generate 

Mission  Plan 

8 

2 

A2.2  Track  Reference 

A2.3  Manage 

Formation 

A2.4  Navigate  UAVs 

A2.5  Generate 

Control  Commands 

A3.1  Manage  Sensors 

A3. 2  Track  Point  Of 

Interest 

A3. 3  Generate  Sensor 

Commands 

A4.1  Process  Data 

A4.2  Record  and 

Playback  Data 

A4.3  Interpret  Data 

A4.4  Produce 

Surveillance  Product 

1.  Perform  Ground  Control  Functions 

1.1.  Perform  Operator  Functions 

l.l.l.Provide  UAV  Control  Inputs 

x 

x 

X 

X 

x 

1.1.2.Provide  Sensor  Control  Inputs 

x 

x 

x 

x 

1.1.3. Provide  Mission  Planning  Inputs 
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2.  Perform  Airborne  Control  Functions 
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Appendix  K:  Test  OV-1  System  Concept 


Figure  66.  Test  OV-1  System  Concept 
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Appendix  L:  Test  OV-2  Operational  Node  Connectivity  Description 


Figure  67.  Test  OV-2  Operational  Node  Connectivity  Description 
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Appendix  M:  Test  OV-5  Operational  Activity  Model 


Figure  68.  Test  OV-5  A-0  External  Systems  Diagram 
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UAV  Sensor  Node 


Figure  69.  Test  OV-5  AO  Context  Diagram 
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CUSS  Nodd 


Figure  70.  Test  OV-5  AO  Provide  Surveillance 
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Figure  71.  Test  OV-5  A1  Plan  Mission 
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Figure  72.  Test  OV-5  A2  Manage  UAVs 
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Figure  73.  Test  OV-5  A3  Control  Sensors 
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Figure  74.  Test  OV-5  A4  Manage  Surveillance  Data 
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Appendix  N:  Test  SV-1  System  Interface  Description 


Figure  75.  Test  SV-1  System  Interface  Description 
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Appendix  O:  Test  to  Conceptual  Component  Mapping  Matrix 


Table  9.  Test  to  Conceptual  Component  Mapping  Matrix 


Conceptual  CUSS  System  Components 


Ground  System 

Airborne  System 

Test  System  to  Conceptual 

System  Component  Mapping 

Operator 

Computing  Device 

CUSS  Software 

Ground  Transceiver 

GPS  Receiver 

Communications 

Antenna  (Ground 

Air  Vehicle 

Airborne  Control  Unit 

Sensor  Package 

Airborne  Transceiver 

Communications 

Antenna  (Airborne 

Test  System 
Components 

Operator 

X 

La  ptop 

X 

Monitor 

X 

Manual  R/C  Controller 

X 

VC  Softwa  re 

X 

C++  Interface 

X 

Matlab  Algorithm 

X 

4-Way  Switcher 

X 

DVR 

X 

Maxstream  Modem  in  Commbox 

X 

Power  Divider  (2) 

X 

Video  RX  (8) 

X 

Oracle  Dual  Diversity  (4) 

X 

AverMedia  Video  Capture 

Device 

X 

GPS  Antenna 

X 
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X 
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X 
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X 
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X 

Furuno  GPS  RX 

X 

Kestrel  Autopilot 

X 

Front  Camera 

X 

Side  Camera 

X 

Camera  Controller  Board 

X 

Maxstream  Modem  (Airborne 
System) 

X 

Communications  Antenna 
(Airborne  System) 

X 

Video  Antenna 

X 
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